Re: GDesktopAppInfo

[Alexander Larsson <alexl redhat com>]

On Fri, 2007-03-23 at 18:48 -0400, Dan Winship wrote:
> Hey, Alex, I see you've started porting gnome-vfs-mime to gvfs. I've got
> some questions/comments on that.
> 
> I've been thinking about replacing GnomeDesktopItem lately
> (http://bugzilla.gnome.org/show_bug.cgi?id=415070) and recently realized
> that gnome-vfs has its own completely separate .desktop file
> parsing/executing code (which has now been ported to gvfs). We should
> fix this duplication.
> 
> Right now the biggest problems with using GDesktopAppInfo as a generic
> GnomeDesktopItem replacement are:
> 
>     * no way to create a GDesktopAppInfo for an arbitrary .desktop file
>    * no way to get access to non-standard keys in the .desktop file

The API is supposed to be portable (i.e. implementable and usable by
apps on windows) and generic and support the kind of stuff people
normally need. This is done by abstracting the platform implementation
(desktop files on unix, registry on win32) and wrapping all the code
inside the abstraction. Do many apps really require creating launchers
from arbitrary desktop files? What is the typical usecase of that?

If this is required, maybe we can have a unix-specific API similar to
gdkx.h that lets you do this.

>     * various assumptions that only make sense for the menus/MIME type
>       launcher cases: eg, it skips Hidden=true files, it only deals with
>       Type=Application, etc

Yes, the main use of this is for applications to handle the
mime->application mapping and application launching. I was unsure that
we should even add as much APIs as I did, but we clearly need *some*
mime support in glib if we're gonna return mime info for files, so the
rest of the support sort of flows from that. 

So, in the case where this is used I think the limitations you quote are
perfectly OK. On the other hand, maybe there are usecases where you need
a full implementation of desktop files, such as when nautilus finds one
in a directory you're browsing. Does such an implementation have to be
in glib though? (i.e. its unix/xdg-specific and maybe not widely
needed.)

>     * doesn't implement startup notification by itself
>
> Of course, it *can't* implement startup notification if it's going to be
> located at the glib level in the stack, but I think it's a bad idea to
> have a .desktop-file-launching API that doesn't do SN by itself. Right
> now, apps using gnome_vfs_mime_application_launch() have to either (a)
> cut and paste a huge amount of libsn crap, or (b) not do that, and cause
> the launched app to be thwarted by focus-stealing prevention. Both of
> these suck; the platform should dtrt automatically.

Yeah, the idea was to have higher level wrappers in Gtk+ that support
doing the startup notification. Similar to how we now have g_spawn() and
gdk_spawn(). All the required stuff (supports_sn + pass the env when
launching) is availible in the lowlevel APIs.

> Is there any reason that this API has to be at the glib level?

It clearly would be nice if command line apps can call some of these
functions, but I guess that is not essential. The question is more how
you would place these APIs in the stack otherwise. Clearly we need mime
sniffing in glib, if gvfs is to be at the glib level. That puts xdgmime,
its caches and internal functions in glib. We could put the app launcher
object (GAppInfo atm) and the mimetype -> all/default application
mapping in gtk+, but that code requires calling some "private" functions
in xdgmime that would have to be exported from glib.

> And do you have plans yet for the rest of gnome-vfs-mime and various
> other related things? (gnome_vfs_url_show? eel-mime-extensions?)

Actually, basically all of that is already in, feature wise. The two
things that are missing atm is:

* Ability to create a new mimetype given a glob/extension. 
This used a lot of libxml parsing code to implement updating the
Overrides.xml code, which was hard to do in glib. Its also not exatly a
common operation, and I wouldn't be adverse to just having special code
in nautilus to handle this. (I don't think anyone else will use this
operation.)

* default uri protocol handler info is stored in gconf
This makes it hard to do the last mile of gnome_vfs_url_show() support
in glib. I'm not sure what we should do here. Move the storage of these
settings somewhere else? Mirror it to xsettings (requires Display)? Some
plug-in hack so that we can read gconf keys (although this has problems
with gconf non-threadsafeness).

(also missing atm is the win32 implementation...)

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a lonely zombie hairdresser on a mission from God. She's a strong-willed 
winged bodyguard who can talk to animals. They fight crime!