Dominik Vogt a écrit :
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.

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.

Some users use fvwm with kicker, gnome-panel, kdesktop or nautilus.

 * If fvwm is not running under a DE, these features are utterly
   useless.

Not all: strut, icons and mini-icons, fullscreen, resizing by the
bottom-right of the client, automatic stacking (yes some users like
this). It will be good to implement the "Killing Hung Processes" process
and maybe the _NET_WM_STATE_DEMANDS_ATTENTION _NET_WM_STATE.

 * If running under a DE, using the DE's pager, taskbar, etc. is
   not necessary as fvwm has a rich set of these modules.

FvwmButtons is not GUI configurable, has poor systray support and in
general distributions  does not ship fvwm with their "Distribution
Menu". Kicker and gnome-panel have all these. Also, FVWM as no "desktop
application" (some users like such app ... I do not know why :o)

Also, I use it to monitor user window management activity (for my work).

 * An increasing number of applications mis-uses the EWMH hints to
   do funny things.

Yes. But some application use it properly and if you remove EWMH support
you will have some complaints.

 * 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.

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 suggest to make the EWMH support more configurable (if needed). You
can already almost totally disable EWMH support by fvwm config.

One point is that there is now source indication for client msg. Maybe
we can fix the gaim problem with this.

Also, we do not implement the _NET_WM_STATE_DEMANDS_ATTENTION
_NET_WM_STATE.  Some gaim like problem may be fixed by a proper
implementation of this state I think (gaim may ask for
_NET_WM_STATE_DEMANDS_ATTENTION and we can add a colorset to FvwmIconMan
for this state. Maybe if gtk++ see that _NET_WM_STATE_DEMANDS_ATTENTION
is not implemented it does funny thing like switching to the current
page and desktop)

I may work on these.

I vote for abandoning EWMH support (at least the client messages).

Opinions?


I vote against.

Some applications miss-use the ICCCM spec, do you want to remove ICCCM
support in fvwm?

Olivier

Reply via email to