Gnome root window...

[Bill Mullen]

On Mon, 12 Aug 2002 pll at lanminds.com wrote:

> >>>>> On Fri, 9 Aug 2002, "Bill" == Bill Mullen wrote:
> 
>   Bill> As Gnome appears to have no corresponding ability to
>   Bill> repeatedly execute a program/script for this as KDE does, and
>   Bill> completely ignores the attempts of xplanetbg to draw to the
>   Bill> root window directly, I'm at a loss as to how to get some or
>   Bill> all of this functionality going under Gnome.
> 
> I'm not claiming that I know anything about Gnome or KDE, nor do I fully
> understand exactly what you're trying to do, but couldn't you use 'cron'
> to repeatedly exec your program for you?  Is there a reason it must be a
> desktop/window manager built-in capability?

I'd have to say "yes and no, adding up to maybe." :)

The idea is to allow any user of the machine to choose their WM as they
usually do, and then provide for their use - in a fashion compatible with
the way that that WM manages the root window - the ability to run any one
of a small group of scripts, each of which will initiate an animated
display of Earth on their root window which will run for the duration of
their X session (while retaining the ability to stop this behavior easily
with a similarly simple procedure).

While the HOWTO is targeted at Mandrake users (and I'm trying to keep the
whole thing as newbie-friendly as possible), anyone capable of installing
Hari Nair's Xplanet and a recent wget on their system should be able to
use the tarball as well, with a little editing of the file paths in the
xplanet.clouds.sh and install.sh scripts therein. The other scripts might
work "out of the box", as they merely invoke either xplanet or xplanetbg
with varying arguments, but check the paths in them just to be safe. I
encourage any fans of desktop eye candy here on the list to give it a
whirl, and to tell me what they think. :)

With the "lighter" WMs, it works superbly with the "xpbg" script and its
variants; the window is drawn directly by xplanetbg, and a simple "killall
xplanetbg" and a restart of the WM brings the background back to the way
that the WM originally set it. This allows one to, for example, put "xpbg"  
on one gkrellm button, and "killall xplanetbg" on another, and start and
stop the thing easily using gkrellm from within any of these WMs.

Unfortunately, KDE and Gnome do not permit this. For KDE, I have included
some scripts (named "xpbg-kde*") that work with KDE's built-in capability
to repeatedly execute a program to create a file, which it then displays
as wallpaper.  It means that the "orbiting vantage point" feature of the
standard "xpbg*" scripts is unavailable, but otherwise it works, and the
install script places KDE-style "desktop items" in the appropriate place
(on Mandrake boxes, at least) to make this easily available to all users.
They must manually change their existing wallpaper settings within KDE to
choose one of these options, and then must manually change back to regain
their earlier settings, but this suffices for my purposes.

Cron is certainly one method I can explore for automating the process
under Gnome; as it is now, the install script already configures the
system crontab to retrieve and process the cloud data (by executing
xplanet.clouds.sh hourly). My only concern with using cron here is that it
is vital that the "start the display" scripts be executable with only
user-level privileges, and it is quite possible that the use of cron may
not be available to everyone; for example, Mandrake comes with the popular
Bastille system for script-based firewalling and system hardening, and one
option therein is to restrict the use of cron to only "administrative
accounts". I haven't the first clue how one would test for whether or not
this restriction has been implemented on any given system. Also, some
newbies unfortunately fail to grasp the point of cron and disable it, not
realizing what they've affected until their log files have finally grown
to a size that fills the partition on which they reside, and their systems
begin to exhibit the usual difficulties. :)

It would seem that the method that will provide the highest level of
compatibility with various system configurations, while retaining as much
"newbie-friendliness" as possible, is a series of "start" scripts similar
to the KDE series but which, instead of merely generating a JPEG file and
returning the filename for the WM to display itself, would first generate
the file, then call xsetroot (or similar) to display it, then sleep a bit,
then loop back to the beginning and restart (thereby mimicking the daemon
functionality of the "xpbg*" scripts, and bypassing Gnome entirely).  A
single companion "stop" script, which would simply kill whichever of the
various "start" scripts is running (by executing killall on each possible
script name in turn) would then be possible.

The only drawback to this method seems to be the need to determine from
within these "start" scripts the geometry of the current root window, to
be able to pass that data on to xplanet when it is invoked, and thereby
generate a file of the correct dimensions to completely fill that window
(and avoid any tiling). I would assume that if the size of the virtual
desktop exceeds that of the visible, the geometry of the virtual one would
be the preferable data to use here. Any idea how I might determine this in
a reliable fashion? I'm especially interested in ideas that don't involve
adding a difficult-to-fill new dependency, so the more common and "likely
to be on the distro CDs somewhere" apps are preferable. Anyone know if one
of the ImageMagick apps can do this, for example? Or something that comes
with X 4.x.x itself, or perhaps in the XFree86-contribs package? Can one 
perhaps somehow interrogate the running X server to get this info?

The address for the first-draft HOWTO and the files tarball again:
http://www.lunarhub.com/~moon/xphowto.html

Thanks for the response, Paul, and thanks to anyone else who gives it a
try - or even a once-over glance. I appreciate all feedback of every kind.

-- 

Bill Mullen
3:42am, 2002-08-13