GDesktopAppInfo
- From: Dan Winship <danw gnome org>
- To: "gnome-vfs-list gnome org" <gnome-vfs-list gnome org>
- Subject: GDesktopAppInfo
- Date: Fri, 23 Mar 2007 18:48:50 -0400
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
* 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
* 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.
Is there any reason that this API has to be at the glib level?
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?)
-- Dan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]