On Sun, Feb 24, 2002 at 07:10:33AM +0100, Olivier Chapuis wrote:
> 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
Right. That's one weak spot in the approach I proposed.
> - For some hints clean up is really needed (e.g., the ewmh icons
> that fvwm set itself)
Agreed.
> - 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?
Good point.
> I do not say that the duplication method is bad. I just
> think that for ewmh hints I prefer the "clean up" method.
I agree. Cleaning up the hints is better - but of course it fails
if fvwm is killed the hard way ("pkill -9 fvwm2"). The
duplication methods doesn't have this problem, but on the other
hand is can't deal well with switching to a different wm and then
back to fvwm.
> 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.
Exactly what I'm thinking. And while we do this we should take
care to strictly separate
- Style like hints (honoured at map time)
- State transitions (honoured immediately)
- Hints donated by fvwm (completely ignored by fvwm)
Right now, all this state/style stuff is a mess. Really, the
GNOME/EWMH/OpenLook/Motif/whatever hints code should not fiddle
with the style structures. That only creates a constant stream of
problems. It could be done like this:
1) Write a unified "hints" library that handles all kinds of
hints (GNOME/EWMH/OpenLook/Motif/SM, the application's icon
hint and whatever 'hint' fvwm sets itself during a restart or
recapture).
2) The provided hints are all stored in a separate part of the
FvwmWindow structure.
3) The hints code does not touch the window style structure
anymore.
4) Instead, all window features that can be controlled by hints
have a function in the hints library that takes the window
structure and the setting from the window style as input and
returns if the feature is to be used or not. For example:
hintlib_starts_sticky(FvwmWindow *fw, Bool style_is_sticky);
hintlib_is_maximize_allowed(FvwmWindow *fw);
...
These funtions are the only way to access the hints from
AddWindow() and other parts of fvwm. Not that things like
GNOME_IgnoreHints must be read from the FvwmWindow structure
since the functions don't have access to style structure (I'm
not happy about GNOME, EWMH, SM, ... accessing the style
structure anyway. It should be strictly local to style.c).
5) The hints that are to be donated in some way get similar
functions:
hintlib_set_sticky_hint(FvwmWindow *fw);
...
The code in the library takes care of doing the right things.
This way, all the EWHM_...() and GNOME_...() calls should go away
and be replaced with more general versions.
> 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.
The longer I think about it the more 'hints' come to my mind.
Let's sum up again what we have at the moment:
- GNOME
- EWMH
- Motif
- OpenLook
- Hints set by the application, e.g. StartsIconic or the icon
pixmap
- Preserved states from session.c
- Hints set by fvwm itself
- Styles
It's no wonder that states keep breaking again and again.
> Any way I do not think that this unification is a must.
Considering all this, it seems more important than I initially
thougt. Let's give it a fancy name and put it on the to do list.
How about "Great Hint Code Unification" (aka GHCU) ;-)
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
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]
