After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 106868 - No good way to add to global short-list
No good way to add to global short-list
Status: RESOLVED NOTABUG
Product: gnome-vfs
Classification: Deprecated
Component: MIME and file/program mapping
2.0.x
Other other
: Normal normal
: ---
Assigned To: gnome-vfs maintainers
gnome-vfs maintainers
Depends on:
Blocks:
 
 
Reported: 2003-02-23 17:55 UTC by Toralf Lund
Modified: 2007-01-16 10:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Toralf Lund 2003-02-23 17:55:37 UTC
As far as I can tell, there is no good way to add another handler to the
global (default) short-list for an already-known MIME type, e.g. from the
installation package for the application. There seem to be two ways to
update the list:

1. Edit gnome-vfs.keys, or whatever .keys file orignally configured the list.
2. Add another .keys file with a short-list that completely replaces the
original one, and hope that definition is read after the original one.

neither of which I consider to be very good.

Or to put it differently: It seems like the config structure is based on
the assumption that the GnomeVFS maintainers know about all applications
(or all the "good" ones, anyway) that can handle a given type, which is in
my opinion bad design.

Another question is whether we want to have the short-lists at all, based
on the now-familiar arguments about over-configurability etc.
Comment 1 Christophe Fergeau 2003-04-15 19:35:14 UTC
I thought a bit about the whole mime database mess over the week end,
and I think the short list system should be replaced with some
"relevance" system (a la kde): each app sets a relevance value for
each mime type it supports (the lower, the more appropriate the app is
to handle a given mimetype). So for example, eog would get a relevance
of 10 for png images, while mozilla would get 60 (these are mostly
random numbers for now :p).
The short list would then be the 3 more relevant apps, or the apps
whose relevance is <50 or some system like that.
That would also solve your problem at the same time :)
Comment 2 Toralf Lund 2003-04-24 07:44:38 UTC
Yes. I like the idea. The only possible problem would be that the
config files, and the algorithms used to set up the lists, could get
too complex. In which case a cruder approach like splitting mime_types
in application-registry into "primary" and "secondary" types, or
something like that, should be considered. ("Short list" call would
return all apps mentioning the type in "primary", while "full" list
would also contain the "secondary" handlers.)
Comment 3 Marco Pesenti Gritti 2004-12-09 16:00:25 UTC
No more short list in the new api/db/gui