Some Suggestions

[James Green <gnome cyberstorm demon co uk>]

Hi all,

Sunday night I checked out gnome-* from cvs. Having compiled it all up,
gotten confused with gnome-core (cvs) claiming to be version 1.0.5, and
typed 'startx', I am starting to investigate software for bugs and so on.

During this course, I have come up with a couple of "issues" I'd like to
see sorted out.

1. Currently, it seems that Drive Mount and CD Player applets aren't
saving themselves upon logout. It brings up a warning with a cancel button
- the cancel button does nothing, and I have to wait for another dialog
telling that the panel isn't closing and may be broken. I can do nothing
but Cancel it and have to rm ~/.gnome/session to bring back the panel
again, and that of course means reconfiguration my session of the panel
again and again.

Now, I like this new Logout menu, and I'd like to save my current session
to a seperate file which could be read in during startup. This itself
could have a configuration tool to allow sysadmins to roll it out across a
network. It would certainly save me a great deal of trouble when thing go
wrong. Could this be extended so that only, say, windows or the panel be
saved or updated in the session?

2. Right now, the only way of using the Menu editor to edit the non-user
section of the foot menu is to login to it using root. This needs changing
I feel, and could be joined with (1) above. If the Control Panel had a
cappet permitting the user, upon the entry of root password, to load up a
selection of global configuration tools, such as one for a session
saver/editor, one for a menu editor, etc., this would be great.

3. When things do go wrong, say the panel crashes, we need some way of
logging back in again and bringing back the panel without losing the panel
configuration. Maybe a temporary session file for each panel that is
maintained on the fly? If these are found, they are loaded back in during
startup and restored into the main session files?

IMHO, if the panel dies (something that was notorious in earlier versions
of GNOME and indeed the version shipped in RH6), logging out requires use
of Ctrl-Alt-Del then rm ~/.gnome/session then logging in and
reconfiguration back again. This is too unfriendly for many users. Some
form of session recovery needs implmentation.

4. Some form of Installation script needs devising. This is not too
difficult for rpms, so maybe this can be done quickly, and maybe src
tarballs really should be an admin-only job, but the users we are aiming
for are desktop ones, not admins neccessarily; a program to maintain and
compile src tarballs for installing such packages as gnome should be
thought up.

I have been thinking of this for some time. Similar to RPMs, a
GNU-standard file could be included in every src tarball, giving
information about it's name, version, dependencies, files, etc., this
could be used by the program to check out the dependencies on hard disk
already, sort out what's in /usr and /usr/local, then run configure and
make install, prompting the user about failures and recommended courses of
action - it could even identify missing dependencies and go to a specified
local mirror to grab a copy of it and install it.

If there were created a GNU-standard for a src tarball file tree (/usr/src
being the prefix, /usr/src/libs for libs, /usr/src/wm for window managers,
/usr/src/de/gnome for gnome, etc), it could even look for and maintain
local src tarballs for itself. The program could then say, "This program
requires ORBit-x.x.x which is not currently held on your system - I can
try grabbing a copy off your local ftp mirror site and install it, or I
must abort this installation (OK | Cancel)".

Unfortunately, I'm not qualified to say, yes, this could work, because my
programming experience isn't based on Linux/Unix or even within a GUI, but
it does come from an end-user perspective. Presumably, one can pipe the
output from configure and make into grep and check for standard sentances
like "Package: <package>-<major>.<minor>.<patchlevel> not found" and act
on them. Saving of these warnings/errors should also be available.

Still, this suggestion isn't GNOME-specific, but I include it here because
someone might develop it with a GNOME-front-end.

Just some thoughts.

-- 
James Green
http://www.cyberstorm.demon.co.uk/
Home of the demon.tech.modems 56k FAQ.