Dominik Vogt a écrit :
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.
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.
* If fvwm is not running under a DE, these features are utterly
useless.
* If running under a DE, using the DE's pager, taskbar, etc. is
not necessary as fvwm has a rich set of these modules.
* An increasing number of applications mis-uses the EWMH hints to
do funny things.
* 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 vote for abandoning EWMH support (at least the client messages).
Opinions?
There have been so many interesting responses that I can't reply
to them individually.
To summarize what I understood:
* Some people want EWMH support for third party pagers, taskbars,
panels, etc.
* Fullscreen is a useful feature.
* Nobody(?) cares about *client messages* (other than
fullscreen) that are not sent by pagers, etc.
* EMWH *hints* are generally considered useful.
So, I suggest the following defaults:
* Hints are fully supported.
* Fullscreen messages are honoured for all windows by default.
* Client messages with source indication class 2 (pagers, ...)
are honoured by default.
* Client messages with source indication class 1 (other apps)
are disabled by default.
* Client messages with source indication class 0 (not set) are
disabled by default.
* Client messages without source indication are honoured by
default. Unfortunately, if an application uses them, there is
no way to disable them selectively.
Yes, this seems reasonable. Regarding _NET_ACTIVATE_WINDOW we may
have 3 functions:
EWMHActivateWindowFunc # the one we have, for class 2
EWMHActivateClientWindowFunc # class 1
EWMHActivateLegacyWindowFunc # class 0
in addtion with some styles which enable/disbale the
_NET_ACTIVATE_WINDOW client msg (I've these functions here but not the
styles).
Rational: what I've recently prototyped is an implementation of a
demands attention state (which, in particular, implement the
_NET_WM_STATE_DEMANDS_ATTENTION EWMH STATE). This state can be set by a
fvwm command DemandsAttention and is set in the window flags structure.
It is unset automatically when the window is "activated". For now I've:
AddToFunc EWMHActivateClientWindowFunc
+ I DemandsAttention On
AddToFunc UrgencyFunc
+ I DemandsAttention On
and I've added some colorsets/button state in FvwmIconMan for buttons
which represent a window with the demands attention state (Moreover,
such buttons are always shown in IconMan). This way if an application
want to be activated (using _NET_ACTIVATE_WINDOW or the Urgency hint)
the window is not activate but a red button appear in my IconMan.
Also, the DemandsAttention state is set when a
_NET_WM_STATE_DEMANDS_ATTENTION EWMH STATE client msg is received and
when a window is mapped not visible (useful for my IM windows which are
on page 1 1 with the SkipMapping style). All this is not very original
(some wm and taskbars have already all this), but I think this is useful
for preventing focus grabing which is really a big problem. Now the next
step is to detect when an application use XSetInputFocus, and then
reject the Focus and set the demands attention state (this is surley not
so easy but I think we can do something in the most important cases).
Olivier
