[Gpephone-devel] Adding new entry to .desktop file

[Nils Faerber]

Florian Boor schrieb:
> Hi,
> 
> Nils Faerber schrieb:
>> For me this translates as, the desktop file will contain all mimetype an
>> application can handle. Then there is the mimetype database where
>> applications can add the "verbs", i.e. actions. The tutorial (above)
>> shows an example for Gimp:
>> 	<desktop:can-edit-with>gimp.desktop</desktop:can-edit-with>
>>
>> It is not clear to me yet where this information will end and how to use
>> it. But it seems to me the correct start of the track - if there is
>> already a standard wayof doing it, we should try to use it.
> 
> I'm not sure if this is exactly what we want to use. That means that we use the
> shared mime database and application provided overrides to it instead of
> providing the data in the desktop files themselves. We could do this but then we
> get a lot of additional complexity such as a second database that needs to be
> merged from several files and the need to provide an xml file for each
> application that handles a mime type.

Sure, but we should also at least try to be compatible with as much as
we can. And since Gnome/KDE already use this way, we should at least try
to look at it.

> The desktop file standard allows extending the desktop files by custom data
> fields where the name of these fields has to start with 'X-' indicating a
> non-standard entry. That means we can extend the desktop files without breaking
> standard compatibility.
> An alternative way to provide both mime types and related actions could be
> something like this:
> 
> MimeType = text/html;text/plain;text/pdf
> X-MimeCapabilities = open,edit;open,edit;open

The above example ia anything but obvious - if you remove one mimetype
from the list (apart from the last) the whole list of actions needs to
be shifted too - this smells like maintenance hell and hard to debug.

> Once we are sure our solution is useful in real life we could propose it as an
> extension to the standard.

Sure.
But first we should make sure not to reinvent the wheel and if we do we
have to make sure that we have profound reason for it.

> A related problem is the desired way of selecting the right application for an
> action. The mime database supports to put a priority into the xml file but that
> means that the information which application to use is shipped with the
> application itself. For security and reliability reasons we need a way to teach
> gpe-applauncher only to use a predefined application for some mime type. This
> information should never be part of the application package itself. For all
> types/actions that are not bound to a single handler we need to offer some user
> interface to allow the user to select the preferred handler for these.

The tutorial explicitely sais:
"Note also that information added to the database should be static
("gimp can edit PNG files"), not configuration ("gimp is the preferred
editor for PNG files"). See the shared configuration system for storing
configuration information."

This means that the "preferred" application is a configuration option
and not a static application attribute - which IMHO makes sense.

> Greetings
> Florian
Cheers
  nils faerber

-- 
kernel concepts GbR        Tel: +49-271-771091-12
Sieghuetter Hauptweg 48    Fax: +49-271-771091-19
D-57072 Siegen             Mob: +49-176-21024535
--