On Fri, Feb 22, 2002 at 11:35:58PM +0100, Dominik Vogt wrote:
> With GNOME and EWMH we now have a flood of different methods to
> specify style and state of a window that compete against each
> other.  Since there already are a lot of problems, I think we need
> to redesign how hints/styles/states are applied to a window.
> Right now we have:
> 
>   GNOME hints set by the application
>   GNOME hints set by fvwm
>   EWMH hints set by the application
>   EWMH hints set by fvwm
>   Hints set by the application
>   Fvwm's styles
>   Fvwm's window states
> 
> For some styles/states it's already almost impossible to keep
> track of the proper hint to use.  The latest example is the GNOME
> layer hint:  when fvwm creates a window, it sets that hint.
> Later, if you recapture the window or restart fvwm, fvwm finds the
> layer property on the window and overrides the style, even if it
> changed.  Note that this happens for windows that never set any
> GNOME hints themselves.
> 
> I propose the following solution for the external hints (GNOME,
> EWMH and possibly others in the future):
> 
> Every window property that is defined externally is duplicated
> with an FVWM prefix.  E.g.
> 
>   NET_WM_FOOBAR --> FVWM_NET_WM_FOOBAR
>

I used such solution (in a not perfect way) at some point with
fvwm-ewmh (the module and the patch I wrote, not the 2.5.x ewmh
support). An other solution (used in the 2.5.x ewmh support) is to
keep in the FvwmWindow structure the "initial ewmh state" and
when a window is unmapped/reparented/recaptured/"restarted"
fvwm clean up the ewmh hints accordingly (delete the ewmh icons
that fvwm set itself, remove some ewmh state and restore the initial
ewmh hints set by the application in some case, ...etc.).
I think that this solution is more robust than hints duplication
(but there are probably still some bugs at present time, even if
I fix some after your remark about iconified/shaded FvwmButtons
panel):
- If an other wm is started it seems to me that the clean up
method is better
- For some hints clean up is really needed (e.g., the ewmh icons
that fvwm set itself)
- The NET_WM_STATE hint must be set by fvwm to the current
state of the window (as ewmh pager/taskbar get the information
on the windows using this hint). So here it is not clear how to
use the duplication method: FVWM_NET_WM_STATE should be set
to the initial (application) ewmh state? And after?

I do not say that the duplication method is bad. I just
think that for ewmh hints I prefer the "clean up" method.
There is no problem for using the duplication method for
GNOME hints and the clean up method for EWMH hints.
But maybe the good solution is to unify the GNOME and
EWMH code. Of course I think that if we do that we should
move the GNOME code into the EWMH code which is IMHO better
(e.g., it is easy to extend it) but maybe more difficult
to understand at the beginning. Any way I do not think
that this unification is a must.

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]

Reply via email to