Hello. Right now I'm implementing my own window manager. Mainly because I'm not satisfied, what existing WMs provide or the way I have to configure those WMs which are closely to what I like. And the later unfortunately don't all implement things you need in a modern desktop.
So I'm reading the specifications about X11/X.org and FreeDesktop.org - and at times went WTF?! to some higher power, because of, well... TSWAHELLAN and NIH. This is my first of probably a series of rants to come, especially about what's going on with xdg. My concerns are mainly attributes to the "to someone with a hammer, everything looks like a nail" (TSWAHELLAN) and "not invented here" (NIH) problems of the xdg folks. I'd like you to look at <http://www.freedesktop.org/wiki/Specifications/StatusNotifierIcon> specifically at <http://www.notmart.org/misc/statusnotifieritem/basic-design.html> | The Status Notifier Item system relies on inter-process communication | via D-BUS and is composed by three parts: (...) And then think about this: xinit /sbin/ssh -X $REMOTEHOST $START_DESKTOP_SESSION_CMD or, even just something simple like ssh -X $REMOTEHOST $SOME_PROGRAM_USING_THE_SYSTRAY from a running X session. D-BUS won't work here, because SSH doesn't tunnel it. Oh yes, SSH could be expanded to implement it. But then there's the next problem: What about connecting from a X server/system where there's no D-BUS? Yes, those exists, and they're plenty. I understand, that there are some issues with the current systray mechanism, the biggest I agree with is about interaction with modality. But I highly disagree with the way how the proposed specification addresses this. And let's face it, the current XEmbed systray does it's job quite well, and the problem is not that systray is inherently flawed, but that the programs using it have bugs or don't conform. Let me cite from the ICCCM: > -- 1. Introduction -- > > It was an explicit design goal of X Version 11 to specify mechanism, > not policy. As a result, a client that converses with the server > using the protocol defined by the X Window System Protocol, Version > 11 may operate correctly in isolation but may not coexist properly > with others sharing the same server. > > Being a good citizen in the X Version 11 world involves adhering to > conventions that govern inter-client communications in the following > areas: In this case I impeach xgd/freedesktop having a particular brainchild, err hammer, named D-BUS and now the people involved try doing about everything using that. There's nothing wrong with it per se, but using it for inter X-client communication is just wrong. We got ICE and ICCCM for that. Use it, it exists for a long time. D-BUS was introduced to have a concise system for IPC between system and user session processes, or user processes not already running within an environment, where a standard means of communication exists. Don't get me wrong, I'm not against D-BUS. It is a very well designed system with it's own proper set of applications. Of course there are useful scenarios in which also X-clients may want to exchange data using D-BUS - the best way to identify those is, doing the mind experiment, if the programs in question may be running in different sessions and there's still usefull stuff to communicate. If yes, then use D-BUS, else if no, then use a simpler method that stays within the session. Some of the (proposed/draft) specifications on FreeDesktop.org are highly redundant and some parts of their design have been deliberately abandoned in existing specifications for good reason. Mainly it boils down to: "Don't reinvent the wheel, especially if the reinvention is inferior." Just my 2 cents Wolfgang _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
