spec on "multimedia buttons"

[Olivier Chapuis]

On Fri, Aug 01, 2003 at 05:47:22PM +0200, Lubos Lunak wrote:
> On Friday 01 of August 2003 14:14, st at stereolyzer.net wrote:
> > Hello,
> >
> > i'd like to ask for your opinion on a common spec for handling
> > "multimedia keys" like volume +/- which are commonly used on laptops
> > and (recent) usb keyboards.
> >
> > Let me briefly describe a showcase using the above example setting
> > volume (for GNOME volume-applet):
> > When the user modifies the volume via keys the volume-applet on the
> > panel is activated and moves the slider up and down following the
> > user input.
> > So we wouldn't have to ways of displaying and setting the actual
> > volume level with gtkpbbuttons / applet for keyboard / mouse.
> >
> > I think apple does something like that on OSX.
> >
> > The same would apply to screen brightness.
> >
> > Sorry if that's already an old topic, I might have missed the search
> > function on the list archives.
> 
>  I don't see any point in doing this. If you want the volume+/- multimedia 
> keys to raise/lower volume, simply bind them to volume up/down keyboard 
> shortcuts for your mixer application (applet, whatever). I have the KDE's 
> kmixapplet configured this way. All that's required is having correctly 
> configured keyboard for this to work.
>

First I understand why ksmserver does not restart non XSMP app for me:
ksmserver has support for the old protocol (WM_COMMAND,WM_SAVE_YOURSELF)
only for development versions of KDE and I do not use kwin. 

I take a look at the current ksmserver code. ksmserver has the bug I
describe.  But in the case of ksmserver the simple sm has a
workaround: set the SM_CLIENT_ID property with a dummy id on the
leader windows its manage (and basically this is fine for me).
 
The situation is different for gnome-xsmproxy. It should connect non
XSMP award app to a sm when the window map, so yes gnome-smproxy check
if SM_CLIENT_ID is set or not on a leader window and if not set it
connects the window to a sm (and set the SM_CLIENT_ID property). If
the simple sm does that too there is a race between gnome-smproxy and
the simple sm (the race does not happen with ksmserver because it
looks at SM_CLIENT_ID only when it saves the session). Of course,
gnome-xsmproxy may monitor SM_CLIENT_ID and disconnect the app if it
changes (and I will be happy if it does that). However, I think that a
SESSION_MANAGER property is better (e.g., gnome-xsmproxy may do its
job for more than one sm). Note that adding support for this property
to ksmserver is a 3 lines patch.

Regards, Olivier