Re: ANNOUNCE - GNOME Update Manager
- From: u07ih abdn ac uk
- To: sopwith redhat com (Elliot Lee)
- Cc: u07ih abdn ac uk, gnome-list gnome org
- Subject: Re: ANNOUNCE - GNOME Update Manager
- Date: Sun, 7 Nov 1999 16:10:45 +0000 (GMT)
> 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]