GNOME Bugzilla – Bug 339225
Add new defines for easier handling of .desktop files
Last modified: 2007-05-30 14:27:30 UTC
Here's a patch that adds defines to make it easier to parse .desktop files with GKeyFile. I'm not sure if it'd also makes sense to also define functions like g_key_file_desktop_get_string() (which would be easy) since it would add a lot of defines. Also, right now, I didn't add some keys: + Encoding: GKeyFile only support UTF-8 anyway + FilePattern: not sure if it's useful + SwallowTitle: + SwallowExec: don't know what they're used to + SortOrder: not sure if it's useful (probably useful) + Dev: + FSType: + MountPoint: + ReadOnly: + UnmountIcon: used for the FSDevice type we never used I also didn't add the deprecated keys. Last thing is, I wonder if we should define an enum for the various possible types, and create a function to get the type of the .desktop file.
Created attachment 63992 [details] [review] Patch
Looks fine, but it misses the documentation part...
Created attachment 64008 [details] [review] Add documentation. Sorry, I had forgotten about this. I'm not sure how verbose this should be and if I put it in the most appropriate place. I hope it's okay.
Created attachment 64063 [details] [review] Variation of the patch This version of the patch also adds g_key_file_desktop_get_entry_type() and g_key_file_desktop_set_entry_type(), which might make sense to have.
I've sent a mail on the xdg list to update the spec and to try to officially deprecate some keys, so it might be worth to wait for a consensus there. Don't know if it's compatible with the API freeze, though.
I'd rather keep the desktop file support to macros, and not add the set_type/get_type functions. Instead, we can add defines for the possible types #define G_KEY_FILE_DESKTOP_TYPE_APPLICATION "Application" #define G_KEY_FILE_DESKTOP_TYPE_LINK "Link" #define G_KEY_FILE_DESKTOP_TYPE_DIRECTORY "Directory"
Vincent, any update on the deprecation of keys ?
(In reply to comment #7) > Vincent, any update on the deprecation of keys ? Of the keys in the latest patch, only "Encoding" is now deprecated. GKeyFile won't deal with Encoding=Legacy-Mixed anyway, so there's no reason to care about it at the desktop file level, so that #define can probably go. (Actually, GKeyFile assumes things about the meaning of "Encoding" keys that it maybe shouldn't...) (In reply to comment #6) > I'd rather keep the desktop file support to macros, and not add > the set_type/get_type functions. This patch is only part of the story anyway; the panel right now uses GKeyFile to parse desktop files, but then when it wants to launch a launcher, it creates a GnomeDesktopItem based on the GKeyFile so it can call gnome_desktop_item_launch. If the goal is to move away from GnomeDesktopItem, we should figure out where the rest of its functionality is going to end up, and then the macros from this patch probably belong there as well. (And if the goal ISN'T to move away from GnomeDesktopItem, then this patch is pointless.) It might be worthwhile to split GnomeDesktopItem into two pieces (gui and non-gui), in which case maybe the non-gui parts could become gkeyfiledesktop.[ch]. Otherwise it probably all ends up in gtk.
Counterproposal: I've redone the GnomeDesktopItem rewrite in EggSMClient. See http://svn.gnome.org/viewcvs/libegg/trunk/libegg/smclient/egglauncher.h?view=markup for the current API. This includes all of the #defines from Vincent's patch, but also most of the rest of the GnomeDesktopItem functionality; I think any application doing much of interest with desktop files is going to link against gtk anyway, so having the #defines there shouldn't be a problem. EggLauncher uses GKeyFile for parsing, letting EggLauncher's own API be more centered around being a launcher for a particular instance of an application. Essentially, the whole API is just gnome_desktop_item_launch_on_screen_with_env exploded into a bunch of much simpler (and more-easily-extended-in-the-future) methods. Since it doesn't depend on gnome-vfs, it has to do its own simple URI handling (converting between file: URIs and paths in some cases), but eventually that would be handled by gvfs methods. Since it doesn't depend on gnome-vfs or gconf, it uses "xdg-open" to open Type=Link .desktop files, and "xdg-terminal" to launch Terminal=true ones. (This is arguably preferable to using gnome-vfs anyway, since you generally want to launch the right browser/terminal for the currently- running desktop, not the right browser/terminal for GNOME.) It *does* depend on libstartup-notification at the moment, but it could be rewritten to implement that by hand. It's a little vague about cross-platformness; it probably doesn't handle Windows filenames correctly, and the xdg-utils obviously aren't going to exist on Windows. But do we really care about launching desktop files on Windows anyway? This might be an X11-specific API? What do you think?
It does make sense to kill GnomeDesktopItem, IMHO. I'm not good at commenting on API, but it looks okay. Maybe some people would like to have it look a bit more like the g_spawn API? I believe we should still define the macros in glib, though, since there might be some non-graphical programs wanting to parse .desktop files. Also, I'm not really fond of using xdg-open and xdg-terminal, but this can be fixed later.
ok, I filed a new bug, bug 415070, for EggLauncher / GnomeDesktopItem replacement
Dan, using xdg wrappers in this way sounds like a recipe for infinite recursion... xdg wrappers are (presumably) implemented using native desktop technology. If the native desktop technology starts to call back into xdg wrappers, bad things will happen...
(In reply to comment #12) > Dan, using xdg wrappers in this way sounds like a recipe for infinite > recursion... replied to in bug 415070
Created attachment 89010 [details] [review] revised G_KEY_FILE_DESKTOP_* patch After playing around with EggDesktopFile a bit, I've realized that apps that actually create or modify .desktop files (rather than just reading them) need to have detailed knowledge about the spec already anyway, so there's no advantage to them to using a desktop-file-specific abstraction rather than using GKeyFile directly. So I agree that having desktop-file-related defines in GKeyFile is useful. So here's an updated patch addressing Matthias's comments. Relative to the patch in comment 3, this: - removes G_KEY_FILE_DESKTOP_KEY_ENCODING, since it's basically a fossil, and GKeyFile only supports UTF-8 anyway - removes G_KEY_FILE_DESKTOP_KEY_ACTIONS, since it's not in the spec at all - adds G_KEY_FILE_DESKTOP_TYPE_APPLICATION etc as suggested in comment 6 - moves the defines and the docs to the bottom of the files
Looks fine; small documentation tweaks might be nice to do when committing: - add "Since 2.14" to all symbols - "The value is a string" and similar sound a bit wrong in this context, since this is just the doc for a macro expanding to a certain string... Maybe say something like "The desktop entry specification allows string values for this key"
I merged the value types into the description: "A key under G_KEY_FILE_DESKTOP_GROUP whose value is a localized string giving the generic name of the desktop entry." etc 2007-05-30 Dan Winship <danw@novell.com> * glib/gkeyfile.h: add defines for desktop file handling. #339225, original patch from Vincent Untz.