RE: Converting to XSMP from WM_SAVE_YOURSELF - solved

["STYMA, ROBERT E (ROBERT)" <stymar lucent com>]

> Subject: Converting to XSMP from WM_SAVE_YOURSELF
> 
> 
> I have an X11 program which is written in C
> and uses only libX11.so calls.  (No intrinsics,
> no Motif, no widgets)  I am adding support
> for XSMP and am currently testing on Linux
> Fedora Core 3.  
> 
> Using the:
>       X Session Management Library
>       Version 1.0
>       X Consortium Standard
>       X Version 11, Release 6.7
>       Ralph Mor
>       X Consortium
> as a guide.  Fine piece of work Mr. Mor.
> 
> I have built a test program which works
> and incorporated the calls and callbacks into my
> program.  All the calls work as documented and the
> X11 program is restored after logging off and logging
> back on.  (I am running with "Automatically Save
> Changes to Session" turned on in the preferences.)
> Debugging info shows the callbacks are called as expected
> and the $HOME/.gnome2/session looks good.
> 
> My save state information is all held in the command line
> so I am not using the SM properties dealing with the
> state file.
> 
> The problem I am having is that when I log out, I still
> get the message:  "These windows do not support Save Current
> Setup ..." message on logoff.  It flags the window which has
> the new XSMP code.
> 
> Is there anyone on the list who understands libSM.so well enough
> to know why I am still getting this message and what needs to be
> done to clean this up?
> 
> Three additional pieces of information:
> 1.  I have not removed the WM_SAVE_YOURSELF code as some platforms,
>     like Solaris 8 and HP/UX still use it.  I also still set 
> WM_COMMAND
>     as I use that property.
> 
> 2.  I do not see in any of the calls how my connection to the 
> Session Manger
>     is identified to belong with the particular main window.  
> The Session Manager
>     could be very sneaky and use techniques similar to XKill, 
> I suppose.  I do
>     not see any calls in the documentation where I tell the 
> Session Manager the
>     window ID.
> 
> 3.  I have tried setting up the Session Manager connection 
> both before and 
>     after the X windows were created.
> 

Since no one answered, here is the trick, now that I figured it out.
You have to set property SM_CLIENT_ID on the top level window 
you choose to be the client leader window before you map the
window.  The property gets set to the client ID returned by
SmcOpenConnection.

If you just have one main window open, it can be the client leader.
Or you can create a window which you never map and set the SM_CLIENT_ID
on that window.  All the other main windows you create then have the
WM_CLIENT_LEADER property set to the window id of this never mapped leader
window.  This is handy if windows come and go.

Just remember, SM_CLIENT_ID and WM_CLIENT_LEADER have to be set while the window
is unmapped.