On Thu, Jul 17, 2003 at 12:47:28AM +0300, Mikhael Goikhman wrote: > On 16 Jul 2003 21:53:37 +0200, Olivier Chapuis wrote: > > > > On Wed, Jul 16, 2003 at 09:21:06PM +0200, Olivier Chapuis wrote: > > > On Wed, Jul 16, 2003 at 06:08:41PM +0200, Olivier Chapuis wrote: > > > > > > > > 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 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. >
see below. > > > 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: > > > > Ok sorry it is already the case. > > > > > - 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. > > Old application do not support XSMP (I think xterm already supports > XSMP, but probably rxvt does not). > my rxvt support XSMP. > 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. > Agree. > 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. > 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 -- 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]
