GNOME Bugzilla – Bug 661763
desktop-app-info: Add support for X-GNOME-Keywords
Last modified: 2011-10-18 14:01:33 UTC
See patch. Having this API in GIO is not a hard requirement for supporting X-GNOME-Keywords in gnome-shell's search, but not having it will likely mean that .desktop files have to be parsed twice.
Created attachment 199000 [details] [review] desktop-app-info: Add support for X-GNOME-Keywords With search gaining traction as being the preferred way to locate applications, the existing .desktop file fields meant for browsing often produce insufficient results. gnome-control-center introduced a custom X-GNOME-Keywords field for that purpose, which we plan to support in gnome-shell as well.
Review of attachment 199000 [details] [review]: I share Colins slight concern that we need to find a good way to document these desktop spec extensions for app writers. The patch looks fine, but please make sure that you add the new symbol to gio/gio.symbols and docs/reference/gio/gio-sections.txt when committing. ::: gio/gdesktopappinfo.c @@ +670,2 @@ /** + * g_desktop_app_info_get_categories: Copy-paste error here.
Attachment 199000 [details] pushed as 1ed88f0 - desktop-app-info: Add support for X-GNOME-Keywords (In reply to comment #2) > The patch looks fine, but please make sure that you add the new symbol to > gio/gio.symbols and docs/reference/gio/gio-sections.txt when committing. Gah, sorry - I always forget about those. Fixed. > ::: gio/gdesktopappinfo.c > @@ +670,2 @@ > /** > + * g_desktop_app_info_get_categories: > > Copy-paste error here. Fixed as well.
My primary concern here is: if Keywords were to become part of the spec, it might have different semantics and then it won't be possible to change the function. get_gnome_keywords would seem the safer choice, with the side effect of making clear that it's not part of the spec.
Hmmm, I see the point, but is this really something we can realistically expect to happen? I'm obviously biased, but I can't imagine a "keywords" property being anything but a list of strings. Anyway, in case we do want to play safe, I'd suggest the following: - leave the method name for the moment (there are 1-2 expected consumers of the API, so the fallout from a name change late in the cycle is minimal) - bring it up on xdg - if we can get it standardized this cycle, good for us - if not, rename to get_gnome_keywords