Re: ANNOUNCE - GNOME Update Manager

[u07ih abdn ac uk]

> 	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.

I'll add it to the TODO list.

> 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.)

Personalise/Setup

> 
> 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. :)
> 

So, what you're suggesting is, instead of just having an <EXEC> tag, which
contains a program to run to do a specific task (say to add desktop icons, or
display a README), GUM has commands tags and it would add the desktop icon or
show the README itself?
I like this :)
Obviously, the cute little icons would have to be drawn by someone with more
artistic ability than myself (see the GUM icon in the foot menu if you need a
reason for this)

> 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.
> 
I was thinking about this, but I'm not sure the best way to do it. At the moment
the "Remind me later" button is if you're logging on quickly to see a file or
read an email, and you don't want to be hassled with "installing" all the new
things that pop up.
I suppose one way to do it would be to keep a text file list of all the files
that you have added to the "install later" list, and just reload them at startup.

> 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?

It doesn't have to add menu items, it was just an example that I did for
testing. 

> 
> 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 
> 
My idea was for it to look something like a druid/wizard, but I can't draw very
well, so I changed it so that could either be a logo for the
company/organisation, or a GUM logo. By text, do you mean text explaining what
GUM is and what it wants to do, or just "GNOME Update Manager"?


> 	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.
> 
If it installs the icons itself then this is perfectly feasible, I suppose.

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

Yeah, I forgot to fix that.

> 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 )
> 

The reason I did it so that it only parsed .gum files in subdirs was so that
each package that was installed had to keep all it's files together in a
directory so that a system admin could quickly 
rm -rf $(prefix)/share/gum/packagename and be sure that he got all the right
files. Another reason was namespace, say for example gnumeric installs a script
called addicons.sh and so does GIMP and they both install it in the root gum
dir. One is going to be overwriten. 

> 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. :)
> 
Well, if I bring in the RPM database can I get the time that the RPM was
installed at, or would it still give the time the RPM was made?

> Nice work, though, and clean code.
> 
> Hope this helps,

Thankyou, and I guess your suggestions will help a great deal

iain