Re: ANNOUNCE - GNOME Update Manager

[Elliot Lee <sopwith redhat com>]

On Sat, 6 Nov 1999 u07ih@abdn.ac.uk wrote:

> I've finally got a release together for the GNOME Update Manager (or GUM for
> short). This is version 0.2.2 and is the first public release and I'm just
> hoping I've not forgotten anything, and it'll work on other people's machines.
> 
> GUM is a program that will inform users about software that has been
> added to the system since they last ran GUM. As GUM is normally run
> everytime GNOME starts, that should be the same as the last time the
> user logged on. GUM can also show messages to certain people, and
> offer install options (like for example "Install icons onto the
> desktop") that the user may like to run.

		A Microsoft stock in my possession (aka My $0.02 :)

	Data sources:
Any plans to support reading the system package database? I know at least
rpm has information on the installation date, etc. - by using librpm, you
could find all packages that had been installed since last login, and you
could list the files in those packages to find any .desktop files, etc.

Obviously a .gum file can give GUM more useful information than the rpm
database can, but would be nice to handle as many situations as possible.

	Interface:

If the application is already installed on the system, why does GUM use
the terminology of "installing" it? Maybe "personalize" would be a better
term (this is just one suggestion, though, and I haven't put much thought
into it.)

In other words, it isn't at all obvious just by looking at the window what
GUM is actually wanting to do. I would suggest changing the main screen
area to a GtkCList on the left, with a list of all new applications, and
then on the right you have a bunch of checkboxes:
	[ ] Put icons on my desktop to start this application
	[ ] Show me the README for this application
	[ ] Start the tutorial for this application
These would come from the XML file. If you defined a set of "basic"
actions, you could have columns for those actions in the GtkCList that
indicated whether those actions were selected for each package (I'm
thinking cute little icons here. :)

Since you need to handle "install later", perhaps you could have another
smaller list widget that lists all the packages the user wants to
"install" later.

Since the menu items for the program in question are going to be shown on
my menu anyways anyways, why is it wanting to "install" those menu items
again?

A new user is not going to know what in the world the big "GUM" on the
left means. Perhaps instead it would be helpful to have some text 

	Miscellanea:
Another thing it could do is add a special metadata key onto all the
desktop icons it creates, and then offer to remove those icons when the
application is uninstalled.

Oh, and it would be nice if gum.site didn't exist to treat it as being
"<gumsite></gumsite>".

gumxml_parse_dir() should not be hardcoded to only read
$(prefix)/share/gum/*/*.gum - instead it should read all the .gum files in
$(prefix)/share/gum and its subdirs (or you could just )

How do you intend to handle the fact that file timestamps normally are set
by the package manager? This means that when vmware*.rpm is installed,
/usr/share/gum/vmware.gum may have a timestamp of two months ago, if
you're installing a vmware that was packaged two months ago. (Of course,
you could just require the packages to run 'touch foo.gum' in their
post-install scripts - this is probably the simplest solution. :)

Nice work, though, and clean code.

Hope this helps,
-- Elliot
Do not meddle in the affairs of dragons,
for you are crunchy and good with ketchup.