On Sun, Mar 12, 2006 at 11:41:54PM +0100, Dominik Vogt wrote: > A current discussion with the gaim developers about some gaim > mis-feature has made me think about abandoning EWMH support > completely. In my eyes, the only usefull message it has is the > FULLSCREEN stuff. Everything else is just causing trouble.
Time to stick my head out from the parapet, then. :) > Reasoning: > > * Most of the EWMH features are intended to mix applications written > for the different desktop environments (DE), e.g. a KDE pager with a > GNOME taskbar. Indeed. This is why the EWMH spec was originally written, yes? To address the limitations [1] of the ICCCM specification, and to unify the similar starting projects addressed by both KDE and GNOME as to how clients were to respond to these DEs. I assume EWMHs work well with DE <--> DE in this case, or where a EWMH-client is running under a EWMH-aware DE. Where the problem occurs (that I can see) is when EWMHs are tried to be manipulated by the user. Was this ever an intended feature? It wouldn't seem as though it was -- at least not from what I can tell. > * If fvwm is not running under a DE, these features > are utterly useless. Agreed. > * If running under a DE, using the DE's pager, > taskbar, etc. is not necessary as fvwm has a rich set of these > modules. The problem here is one of convenience for most people, Dominik. As _much_ as I agree with you on this -- in that most EWMH-applications (for things like pagers and taskbars) can and are available in FVWM, not everyone uses them. Some people like the use of KDE's Kicker (shudder) or GNOME's panel. How can you reconcile the removal (potentially) of that feature set if you remove or discontinue EWMH support? > * An increasing number of applications mis-uses the EWMH > hints to do funny things. This is where I see the bone of contention, Dominik. At the moment you're having to almost write EWMH support into FVWNM to address the EWMH's limitations in fixing it, when ultimately the responsibility falls down to the XClient in question. > * Most users have *no* chance to control > such appications. For example, the problem with SkipMapping and gaim > that led to the discussion on the gaim list. It took the user several > days to figure out the problem and had to ask the fvwm developers for > help. There's a dichotomy (see above) between implementing EWMH to the specification given, and then reimplementing certain features to fix the limitations either within the XClient in question, or the specification. I still look at EWMH support as a buzzword. > All this leads me to the conclusion that the EWMH spec (at least the > client message part) offers very little benefits but causes a huge > amount of trouble. It is simply not worth the effort. > > I vote for abandoning EWMH support (at least the client messages). Agreed. (For what that's worth). -- Thomas Adam [1] I can only see "limitation" as being one of stagnation -- i.e. the ICCCM hasn't been formally updated in a while now. -- I've been too honest with myself, I should have lied like everybody else.
