Subject: Need to redesign hints code

From: Dominik Vogt <[email-masked]>
Date: Fri, 22 Feb 2002 23:35:58 +0100

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

When application provides a hint, e.g. the layer hint, that new
property is deleted from its window.  If fvwm sets a hint it sets
the original property and the FVWM_ property to the according
value.  Now, whenever fvwm checks for a hint (recapture, restart,
etc.) it prefers to use its own styles over any GNOME/EWMH hints
that were set by itself (or another fvwm).  So, the normal order
of preference would be:

  EWMH hints (by application)
  GNOME hints (by application)
  Styles
  Application hints
  EWMH hints (by fvwm)
  GNOME hints (by fvwm)

I feel positive that I could do that with the GNOME code, but I
don't understand the EWMH code enough to make the proper changes.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Olivier Chapuis <[email-masked]>
Date: Sun, 24 Feb 2002 07:10:33 +0100

>   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

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 24 Feb 2002 08:24:23 +0100

> - If an other wm is started it seems to me that the clean up

Right.  That's one weak spot in the approach I proposed.

> - For some hints clean up is really needed (e.g., the ewmh icons

Agreed.

> to the initial (application) ewmh state? And after?

Good point.

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

> 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
> 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 ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Mon, 25 Feb 2002 00:42:08 +0100

> How about "Great Hint Code Unification" (aka GHCU) ;-)

Agree, but I am not ready to write the code now in the sense
that I am not really motivated to rework on hints at the present
time. IMHO the conditonal style are more important (but I've
no personal plan).

Olivier