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

[WANG Gang RD-ILAB-PEK]

Hi,

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

My desktop (FC6) has only one application using such .xml file: anjuta, it works well. I will keep digging deeper in this direction to see how much more efforts need to be involved and if they worth it.

Words from the guys of freedesktop are of course important in our decision making!

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

Yes, separating type and verb does pose the risk of inconsistency.


>
> > 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 thorough research is needed. I will do what I said above.


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

since this is not coming with the application itself, maybe we can leave it to the settings system.

BR 
Gang