Re: GDesktopAppInfo

[Dan Winship <danw gnome org>]

Alexander Larsson wrote:
> Do many apps really require creating launchers
> from arbitrary desktop files? What is the typical usecase of that?

Well, the panel in multiple places (main menu, panel launchers, run
dialog). The various panel add-ons/replacements (the Novell main menu
and app launcher, Gimmie, deskbar, alacarte, etc). Nautilus, for
creating launchers for dropped URLs/apps, and launching them later.
Gnome-session for autostart. Beagle, for launching apps in search
results. And then there's xfce-panel, Thunar, etc, etc.

In the realm of the not-yet-deployed, my EggSMClient code uses the app's
desktop file's Exec key to set the XSMP RestartCommand. That also led to
a discussion of having a gtk_set_desktop_file() or
gtk_application_set_desktop_file() method to call at startup, which
would feed EggSMClient the data it needed, plus it could call
g_set_application_name() and gtk_window_set_default_icon_name(), and
possibly do other setup based on loadable modules, like initializing the
bug-buddy signal handlers if the .desktop file includes
X-GNOME-Bugzilla- keys, etc.

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

or have a separate desktop-file-parser class, that also does the things
other apps need that gvfs doesn't, and have gvfs just call out to that
from GDesktopAppInfo.

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

Well, something like gnome-open isn't actually going to be used except
in a GUI environment, so there's no reason it couldn't be linked to gtk
anyway. (And command-line tools to do things like frob the
MIME/application caches, which might get run on a build machine with no
actual X connection, could just use gtk_init_check() instead of gtk_init().)

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

I guess my argument is that g_app_info_launch() ought to be considered a
private function too, because if you call it without setting up startup
notification properly, you're going to end up launching the app into the
background, which is basically never what you want. So the only correct
way to call it is via its gdk/gtk-level wrapper, so it might as well be
considered a private function. And so in that case, moving GAppInfo up
into gtk just changes *which* private functions you're forced to expose,
but it also lets you get rid of some cruft, like
g_app_info_supports_xdg_startup_notify.

-- Dan