On Sun, Dec 16, 2001 at 05:56:48PM +0100, Dominik Vogt wrote: > As far as I understand the code in ewmh.c, the ewmh state hints > modify the style used by a window. Now, if the user uses the > "EWMHUseStateHints" or "EWMHIgnoreStateHints", do windows reflect > that change without a recapture as with all other styles?
In fact EWMHUseStateHints and EWMHIgnoreStateHints are only used at window mapping: if a new window come with some _NET_WM_STATE states with EWMHIgnoreStateHints these states are ignored; that's all so it does not seem that there are problems with style update here. However, after the window has been initialized it is fvwm2 which sets and maintains the _NET_WM_STATE states. So if we want to be dynamic here we must store the initial _NET_WM_STATE states in the FvwmWindow structure to be able to restore/erase these states. This seems not reasonable for me. No?? Moreover, any applications can send a message to change the state of a window (and other things as the Current desktop, the current view port, the active window ..etc.). The problem here is that any application can send a message and it is impossible to know which app send the message. So, at present time all the messages are accepted because I think that for 99% of the cases such messages are sent by the users (via an ewmh compliant pager or taskbar). Of course we can add a style as: Style "match" EWMHIgnoreClientMessage that causes fvwm2 to ignore ewmh client messages which concerns windows which match "match". I can do that if you think that this may be useful (no dynamic update problem here I think). In fact, the good behavior of the previous style is to cause fvwm2 to ignore client messages send by an app whose main window match "match". This is not possible ... Finally, some problems similar to those you mention may arise with the _NET_WINDOW_TYPE types, but at present time nothing here is configurable as I we need some discussions on styles (conditional styles) which are postponed. > I can > remember that this was far from being trivial for the GNOME hints. > The main problem was, that the code in update.c only handles > styles that have the 'changed' flag set (with one of the SCSET_... > macros). But this is only the case for the 'IGNORE_STATE_HINTS' > style, not the ones controlled by it like 'sticky'. > > Olivier, can you define a set of tests to verify the ewmh > functionality? > What do you mean exactly? Here some possible answer. I've written a file a la tests/purify/purify.fvwm2rc for all the new commands and styles I've introduced recently I will merge it one days. I can write a test program but there are already some: just install kde version 2 or 3 and run fvwm2 with any kde app, kicker, kpager and/or kdesktop or even run ksmserver with fvwm2 as window manager. I can give some tips to do so. Everything seem to work fine but a few problems (as menu in kde app with no focus, saving/starting a session on a "right" page (as for GNOME1)). Also last week I have compiled GNOME2 (from the glib2 to gnome-core + nautilus "2" and it ewmh desktop). It is not usable but it seems that fvwm is GNOME2 compliant. Also, gtk+-2 is usable and there is a library "libwnck" (the gnome library for writing pager and taskbar) which has some tests programs. So, what we may need is a FvwmScript or a menu that allows to easily test all the possibility. But the fvwm2 man page plus a FvwmConsole is not so bad. Olivier -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
