On Mon, Oct 02, 2017 at 02:48:01PM +0200, Didier Spaier wrote: > Anyway my point is not which applications to start at boot, rather the > ability to save the session when logging out or rebooting, then > restoring it at next log in. Which Windowmaker does internally:
All WindowMaker is doing is maintainig its own list of windows/applications to open up again. I note from a very quick glance at its code that it tries to use a combination of a client's class/resource and some tricks via XGetCommand() (which will internally look at a client's WM_COMMAND XAtom---which, as I've previouly said---will often yield nothing for most clients). Indeed, WM_COMMAND has been deprecated by the ICCCM2 for some time now. All in all, there's no session manager support in WindowMaker, but it tries its best to do whatever it can internally. > If the user have to interrupt her work and wants to get it back in > the same state later, she can click Save Session then leave, either with > Quit (stopping FVWM and X) or through an external logout feature (in > Slint lxlogout for LXDE, wm-logout for the WMs used standalone.) I understand what Session Management is. > Granted, not all applications will be restored in their previous state, > but that can still save a lot of time. The problem with FvwmSave and FvwmSaveDesk was just that -- there's only a small subset of ways which they can try and work out the mapping between window and process which is what WM_COMMAND is supposed to do, *provided* the application sets that. Now, it could be argued that we could put some additional work into something better/different which recreates FvwmSave---but it's going to be a lot of work for not a lot of real gain, IMO. Indeed, if you look at how FVWM handles recapturing of window states across reboots, you'll note that FVWM maintains a "session" file there which restores a window's geometry, border width, etc., etc. It can do this because the client when added with XAddToSaveSet() is remapped to the root window; that is, the window is still around for FVWM to deal with. But you also have to understand what the difference is between what I'm referring to with FvwmSave and FVWM's understanding of session managers. Session managers that FVWM can talk to do have to conform to some rules -- that was true in the past with XSM/GNOME/KDE, but GNOME/KDE has changed a lot, and FVWM hasn't kept up, and I haven't looked to see what work could be involved in fixing this, or if it's even possible to use these session managers separately. > On the other hand, if you choose not to (re)develop this feature I'd > suggest to edit the man page, as reading it made me think that session > management was still available as described above. Maybe I just > misunderstood this man pages as English is not my native language, but > I guess and hope that I am not the only user in this category. You're the only one to ask in all these years. I'll take a look later on to see if I think there's anything worth changing. I hope my explanations here help you understand the situation with FVWM, and why it's perceived to be working in other window managers (but is still fundamentally broken). -- Thomas Adam
