After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 567721 - get more key/values from GDesktopAppInfo
get more key/values from GDesktopAppInfo
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2009-01-14 09:30 UTC by Stefan Sauer (gstreamer, gtkdoc dev)
Modified: 2013-02-03 05:05 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stefan Sauer (gstreamer, gtkdoc dev) 2009-01-14 09:30:41 UTC
It would be nice to be able to access all fields of the desktop files from GDesktopAppInfo. This might be beyond the GAppInfoIface. One idea would be having

const gchar *g_desktop_app_info_get_detail(GDesktopAppInfo *info,const gchar *detail);

categories=g_desktop_app_info_get_detail(da_info,"Categories");
or
categories=g_desktop_app_info_get_detail(da_info,G_KEY_FILE_DESKTOP_KEY_CATEGORIES);


Also in g_desktop_app_info_new(const char *desktop_id) desktop_id is not clear. Are applications supposed to do: g_desktop_app_info_new(g_get_prgname())? The use case I am looking into is a library which wants to know more about the application that is using it.
Comment 1 Matthias Clasen 2009-01-14 21:02:01 UTC
I don't think g_desktop_app_info is the place to do that.
Just use GKeyFile directly. Of course, you have to figure out what desktop file to load, but GDesktopAppInfo doesn't solve that for you anyway...
Comment 2 Stefan Sauer (gstreamer, gtkdoc dev) 2009-01-15 06:59:31 UTC
Yes, I noticed that shortcomming of the api too. How to get from the $argv[0] / g_get_prgname() to the desktop file. The program name should be there in Exec/TryExec, but I don't think we have API in glb that makes that connection. Would you think such a API is the way to go?
Comment 3 Matthias Clasen 2009-01-15 14:42:04 UTC
It is not a shortcoming of the api, really, but rather one of the many shortcoming of the whole 'stuff it all into desktop files' approach to an application database. There _is_ no clear connection.
Comment 4 Lennart Poettering 2009-02-21 19:20:22 UTC
What about introducing a g_set_application_desktop_file() resp. g_get_application_desktop_file() or suchlike?

That would simply take the .desktop file name without prefix and without suffix. If not initialized defaults to the prgname. And both gtk_window_set_default_icon_name() and g_set_application_name() could be initialized from that.
Comment 5 Dan Winship 2009-02-21 19:50:44 UTC
eggdesktopfile (bug 415070) has something like that, but i think that isn't what this bug is actually about; this is about finding other peoples' desktop files.

(there is a recurring idea of making a .desktop file database a la the icon database, but no one has ever gotten around to it
Comment 6 Stefan Sauer (gstreamer, gtkdoc dev) 2009-03-31 08:31:04 UTC
Also the launchers could export an env-var so that somthing in glib looks for if the dektop file is queried. I am more and more convinced that this is useful, especialy after looking how bug-buddy gets to the desktop file (src/bugzilla.c::get_all_applications()).
Comment 7 Christian Dywan 2009-11-03 13:49:13 UTC
As far as I realize g_app_info_get_id returns the desktop file on Freedesktop.org platforms like GNOME and Xfce. Or is there something still missing?
Comment 8 Stefan Sauer (gstreamer, gtkdoc dev) 2011-03-07 19:21:41 UTC
(In reply to comment #7)
> As far as I realize g_app_info_get_id returns the desktop file on
> Freedesktop.org platforms like GNOME and Xfce. Or is there something still
> missing?

Apps would still need ti lookup the file and parse it. Would be nice to not expose the implementation (GKeyfile) on this api.
Comment 9 Matthias Clasen 2013-02-03 05:05:23 UTC
We now have 
g_desktop_app_info_get_categories
g_desktop_app_info_get_string