First xdg-utils beta release

[William Jon McCann]

Hi Waldo and others,

It was a pleasure talking with you at GUADEC last week.  I am glad that 
we share the goal of providing a sensible and desktop neutral API for 
developers to use.

Here are some of my initial thoughts regarding the xdg-screensaver part 
of the xdg-utils.

I have two primary concerns with the approach:
      1. That the scripts will interfere with or undermine the 
acceptance of the org.freedesktop.ScreenSaver DBUS API.
      2. That the technique currently used by xdg-screensaver is less 
than optimal.


The problem with 1. is that since we are trying to define some kind of 
"standard" it may not behoove us to have more than one.

For 2., there are a number of problems with the way the script API is 
designed.

* It takes a window-id argument

      Just ugly for a generic API.  Potentially X11 specific.  Requires 
a X11 connection.  Potential issues with formatting.  What if the 
application uses a sequence of different windows instead of one?

* It needs to write a file into $HOME

      $HOME may not exist or be writable when the screen is locked 
(think about automounting and expired credentials).  $HOME may be shared 
between systems (eg. NFS) so the filename must include both hostname and 
display information.  It currently only uses display information.  I 
think there are also robustness issues with using a state/lock file like 
this.

* Read the [sic] "Bugss" section of the header in the script

      So, those are problems.

* It uses the suspend/resume terminology instead of inhibit

      I think suspend/resume is overused and too easily confused with 
other types of functionality related to power management.

* There doesn't seem to be any distinction between activating and 
locking explicitly

      It is necessary to make this distinction.

* It seems to imply that the screensaver implementation uses 
MIT-SCREEN-SAVER

      As far as I know there is currently no screensaver that uses it. 
I am looking into it (after discussing some of the limitations with 
Keith Packard last week) but even if it does get used at some point it: 
a) isn't used now b) won't be exposed through the g-s API

      The problem with it not being used right now is that "working 
right now" seems to be the primary goal of the xdg-utils set.

* It unconditionally uses xset before using higher level APIs

     It seems to try to set DPMS settings and stuff using xset.  This 
should be done by the screensaver implementation or not at all.  It 
potentially interferes with things like PowerManager.


So, I think the current implementation of xdg-screensaver is not what we 
should recommend people use.  That said, if we don't have philosophical 
reasons (ie. concern #1 above) for not using a command-line approach I 
think we can fix the above problems by using something that simply wraps 
around gnome-screensaver-command.  The gnome-screensaver-command itself 
is just a convenience around the DBUS API.

In CVS HEAD I added a feature last week that allows the 
gnome-screensaver-command to inhibit the screensaver by calling the 
Inhibit DBUS method and then blocking so it won't leave the session bus 
until the gnome-screensaver-command is killed.  I think this is a better 
way of tracking lifecycle than watching an X window id.

example:
gnome-screensaver-command --inhibit \
--application-name="FooPlayer" \
--reason="Playing in fullscreen mode" &
[do something]
kill %1

What do you think?

Thanks,
Jon