Re: New idea (was: Re: Package managment idea...)

[Matthew Berg <wdomburg pce net>]

> I had an idea in the shower today:  What it each Gnome compliant program
> also
> shipped with a binary/script called <prog>-gnome-init.  This might just be a
> link to the binary that inspects argv[0], but could be seperate.  On startup
> of Gnome, it would look for all *-gnome-init executables in its path and
> execute them.  They could then add whatever icons are needed to the desktop,
> start-menu, blah, blah, blah.

This seems like a long way to go for something that could be stored in a
single database and/or directory structure. 

Especially considering that this is already in place by means of the
/usr/share/apps directory structure for the system menus and the .gnome/
directory structure for the user.  This already takes care of the
desktop and "start" menu entries.  

There are some ways that this could be extended - say by adding a new
additional meta-information for datapath and application defaults. 
Something along the lines of - 

  [Defaults]
    Prefix=/usr/local
    Temp Directory=~/.gimp/tmp
    Swap Directory=~/.gimp
    Brushes=/.gimp/brushes:$PREFIX/brushes

And so on... 

This could be added as either a seperate file from the current .desktop
entried or integrated into the current file.  

Personally, I would like to see this the /usr/share/apps directory be
made less GNOME specific and used for generalized application
information.  Make a library that parses an application file and returns
a hash table of configuration information.

Of course, this would make it a pain to have the GNOME system menu parse
the entire directory tree, so it would become necessary to create a
seperate file to list what entries are actually added to the system
menu.

This would have the added benefit of not requiring users/admins to
delete or move .desktop entries they don't want in the system menus in
order to keep them from showing up - instead you could just delete
reference to them.

> There could even be argument to it: one for first time, one for each
> session, one for shutdown, one for uninstall.

Install and uninstall are package management issues; shutdown and
session are run-time issues.  

Session and shutdown are already taken care of in gnome-libs.  And
package management is taken care of by the distribution. 
 
> To make the process faster at Gnome startup, you could keep a record of ones
> that you have already called, and check to see if the mtime is since them,
> so for a program to get that run again (let say to activate a menu to ask if
> you want to associate a file type with a/the program), it would simple set
> mtime to be the current time, then, next time gnome looks at the
> <prog>-gnome-init executable it would run it.

I'm not sure if I'm understanding you correctly on this one.  Are you
saying that the <prog>-gnome-init executable would be keeping
information such as what file types it's associated with, etc?   

Shouldn't that be stored centrally to cut down on overhead and make
debugging easier? 
 
> The benefits are: the native package system of the system does not have to
> know about it;  it is a good way to add program to anything needed, such as
> 'start menu' (for lack of a better term), desktop, file associating, root
> menu, and much more; third, it is extensible and more calls and things can
> be added and the system wide packing model will not need to be changed.

Well, as I said, I think it makes more sense to keep most of this
information centrally, probably in the /usr/share/apps and
/usr/share/gnomes directory for system wide defaults, and in the .gnome/
directory for user specific.  

The desktop icons especially.  Most people want to have not only
executables on the desktop, but files as well.  This would necessitate
two seperate ways of managing the desktop.  
 
> I know that idea it not fully thought out, but I think that it is an okay
> start for an idea.
> 
> Any comments, suggestions?

I'd definitely be interested in hearing more about the idea.  I'm not
certain I completely understand what you're getting at, but tossing
around ideas is always a good idea.

> (yes I realize that there is overlap between the window managers startup
> file and some of these ideas, but that can all be fleshed out later).

Personally, I think that GNOME would benefit if either there were window
managers designed specifically with gnome, or if there were better
integration tools for the current window managers (say to push the
entries from the GNOME "start" menu to the root menus of common window
managers.

Actually, I was kind of thinking about trying to write the "Ultimate
Window Manager" for integration into desktop environments.  Considering
that projects like GNOME already provide their own application lanchers,
pagers, etc, and traditional window managers usually provide their own,
I was thinking about writing a window manager core that would merely
provide hooks for external modules to provide the window frames, app
menus, etc, etc.  

The idea being that this would allow a replacement of the modules in
order to make it look and feel however you want, without the need to go
window manager hopping like people do now.

But this is off track, and I digress...

Matthew Berg