First xdg-utils beta release
William Jon McCann
mccann at jhu.edu
Fri Jul 7 21:48:28 EEST 2006
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
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
* 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
* 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
It is necessary to make this distinction.
* It seems to imply that the screensaver implementation uses
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.
gnome-screensaver-command --inhibit \
--reason="Playing in fullscreen mode" &
What do you think?
More information about the xdg