Subject: Re: FVWM: GNOME2/fvwm integration

From: Olivier Chapuis <[email-masked]>
Date: Wed, 16 Jul 2003 21:21:06 +0200

On Wed, Jul 16, 2003 at 06:08:41PM +0200, Olivier Chapuis wrote:
> On Sat, Jul 05, 2003 at 10:06:34AM -0400, Tessa Lau wrote:
> > I'm installing Debian unstable and the latest GNOME2 desktop on a
> > friend's system, and I'm trying to convince him to see the light and
> > switch from sawfish to fvwm2.  However I'm running into a few bugs with
> > the GNOME2 integration.  I'm using a freshly built fvwm 2.5.7.
> > 
> > I switch to fvwm by killing sawfish and running fvwm2, then saving my
> > session.  The first time after I log out and log back in with fvwm, the
> > GNOME menu panel, which is always at the top of the screen, has been
> > relocated to the bottom of the screen.  The bottom edge panel has been
> > relocated to the top of the screen.  The menu panel cannot be moved.  If
> > I move the bottom edge panel down to the bottom of the screen where it
> > belongs, it gets hidden behind the menu panel, and is lost forever.
> >
> 
> It is a fvwm bug. I hope that we will be able to fix it soon.
> 
> I switch to the fvwm-workers list.
> 
> The problem is simple: all gnome panels have the same name, icon name,
> res name and class name! So when we restore the window state fvwm/session.c
> is unable to make the distinction between all the gnome panels.
> 
> Any idea for a fix?
>

The obvious idea after reading the SM spec (and the ICCCM2) is to use
the SM_CLIENT_ID property (on a possible WM_CLIENT_LEADER window) But,
at first view the gnome panels have no SM_CLIENT_ID set!!  I think
that sawfish, metacity, icewm and kwin simply ignore window without
the SM_CLIENT_ID property set (on the client leader) regarding session
management.

I think we should add the SM_CLIENT_ID as the main identifier in
the session code and either:
 - do not reset "session state" for windows with an identifier
   (sm client id, name ...etc) with two matching identifiers in the
   session window list.
or
 - simply do not save/restore state for window without SM_CLIENT_ID.

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

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 16 Jul 2003 21:53:37 +0200

> the session code and either:

Ok sorry it is already the case.

Regards, Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 16 Jul 2003 18:08:41 +0200

Any idea for a fix?

Regards, Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 17 Jul 2003 00:27:26 +0300

> is unable to make the distinction between all the gnome panels.

Does not gnome-panel set unique CLIENT_ID? Any SM aware applications
(like fvwm itself) should support (re)starting with a given client id.
Application names are only an additional confirmation.

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 17 Jul 2003 00:47:28 +0300

On 16 Jul 2003 21:53:37 +0200, Olivier Chapuis wrote:
> > at first view the gnome panels have no SM_CLIENT_ID set!!

I did not notice these additional messages before writing my previous
reply.

I think this bug (gnome-panel does not support XSMP and does not set
SM_CLIENT_ID) should be reported to gnome-panel developers.

> > I think

Old application do not support XSMP (I think xterm already supports
XSMP, but probably rxvt does not).

After name comparision there is a command line comparision. So if 2
windows have the same command lines (say "xterm -ls -g 80x40") it is
really not important if we replace them, since they are just indentical.

I can't explain how 2 gnome-panel use the same command lines and open
different panels (one at top and one at bottom). I guess one gnome-panel
process opens 2 windows, at top and at bottom.

I would really fix this in gnome-panel, because the current fix makes
old applications (like 2 rxvt with the same parameters) to lose all
fvwm properties/flags on the next session. This is only my understanding.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 17 Jul 2003 11:20:24 +0200

> SM_CLIENT_ID) should be reported to gnome-panel developers.

see below.

> XSMP, but probably rxvt does not).

my rxvt support XSMP.

> really not important if we replace them, since they are just indentical.

Agree.
 
> fvwm properties/flags on the next session. This is only my understanding.

I do not think there is a gnome-panel bug here: SM_CLIENT_ID and
WM_COMMAND are not set on the managed gnome-panel windows (no leader too).
I think that gnome-panel developer does not want that the gnome-panel state
be restored by the window manager. By the way there is an unmanaged
"gnome-panel" window with SM_CLIENT_ID set.

I think that the correct fix is that session.c totally ignore windows
which do not set SM_CLIENT_ID neither WM_COMMAND. There is no way
for a session manager to start such application at session startup.

Other problems I see with the session code:

- Some session manager now only consider window with XSMP support.
  So an app which use WM_COMMAND will not be started by the session
  manager. So maybe the user will start the app after session startup
  and can be troubled by the fact that fvwm restore the windows app
  state.
  Solution? Detect the session manager and support only XSMP app if this
  session manager support only XSMP app.

- Some app with XSMP support may use the RestartNever style hint.
  The session manager will not start such app at session startup.
  If the user start this app later, again fvwm will restore the state.
  Solution? Can we query the restart style hint or only the session
  manager can do that?

The only general solution I see is a way for the session manager to
say to the wm which apps it will restart at session init.

Regards, Olivier