Re: GDesktopAppInfo

[Alexander Larsson <alexl redhat com>]

On Tue, 2007-03-27 at 15:46 -0400, Dan Winship wrote:
> 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.

Yeah, there is a clear need for this when implementing the Gnome
desktop. But its sort of unix specific, so maybe it doesn't have to be
in the very low levels of the stack. OTOH, its not really a large piece
of code, especially given GKeyFile.

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

Yeah, I could see this working. My only concern is that this would be a
very unix-specific API. I mean, it would *work* on e.g. win32, being
able to parse a desktop file. It just wouldn't be used there. 

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

I just implemented GAppInfo on Win32 (landed today). It also would like
some UI integration (pass it a HWND to have it show dialogs with the
right parent). So, maybe its a better idea to move the GAppInfo stuff to
Gtk+ and expose the mime-type platform specific APIs needed to implement
GDesktopAppInfo as libgtk_only functions. The only parts needed are
_g_unix_content_type_unalias() and _g_unix_content_type_get_parents().

In fact, it turns out that the current g_app_info_launch() API isn't
ideal for win32. Its not possible to pass an environment to the child
when spawning with ShellExecuteEx(), whereas this is essential (for
multihead screen setting and startup notify) on X11. So, we can get a
better API all around if we put this in Gtk+ and abstract out these
features.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a superhumanly strong hunchbacked cowboy on a mission from God. She's a 
cold-hearted insomniac former first lady prone to fits of savage, blood-crazed 
rage. They fight crime!