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 627836 - Add constructor g_desktop_app_info_new_from_keyfile_with_filename()
Add constructor g_desktop_app_info_new_from_keyfile_with_filename()
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gio
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2010-08-24 11:56 UTC by Mikkel Kamstrup Erlandsen
Modified: 2018-05-24 12:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Adds new constructor g_desktop_app_info_new_from_keyfile_with_filename() (3.79 KB, patch)
2010-08-24 11:56 UTC, Mikkel Kamstrup Erlandsen
none Details | Review
Simplify some exisiting logic using the new constructor (1.04 KB, patch)
2010-08-24 11:57 UTC, Mikkel Kamstrup Erlandsen
none Details | Review
Unit tests for the new constructor (1.60 KB, patch)
2010-08-24 11:58 UTC, Mikkel Kamstrup Erlandsen
none Details | Review

Description Mikkel Kamstrup Erlandsen 2010-08-24 11:56:56 UTC
Created attachment 168635 [details] [review]
Adds new constructor g_desktop_app_info_new_from_keyfile_with_filename()

I am attaching a patch series that adds a new constructor for GDesktopAppInfos g_desktop_app_info_new_from_keyfile_with_filename().

When doing detailed work with appinfos I often find myself needing to parse the GKeyFiles manually, extracting some values from it, and then creating a GDesktopAppInfo or the keyfile.

However I am in most cases also in need to have the desktop id and filename of the .desktop file available together with the appinfo as well. So unless I want to do double IO for the .desktop file with g_desktop_app_info_new() in order to set the desktop id on it, I need to invent some containers with metadata for the GAppInfos. This is unhandy and the patches I attach addresses all my needs.
Comment 1 Mikkel Kamstrup Erlandsen 2010-08-24 11:57:45 UTC
Created attachment 168636 [details] [review]
Simplify some exisiting logic using the new constructor
Comment 2 Mikkel Kamstrup Erlandsen 2010-08-24 11:58:10 UTC
Created attachment 168637 [details] [review]
Unit tests for the new constructor
Comment 3 Mikkel Kamstrup Erlandsen 2010-09-06 09:17:24 UTC
If someone would care to review this I can merge it myself if it's accepted.
Comment 4 Allison Karlitskaya (desrt) 2011-02-15 19:33:51 UTC
I don't really care for this API due to the implicit redundancy on the constructor...

I'd really prefer a _get_key_file() API (that would give you access to any extra information you need from the .desktop file).  A _set_id() API is another possibility, but I'm not really sure of the implications of that...
Comment 5 Mikkel Kamstrup Erlandsen 2011-02-16 15:29:52 UTC
Always storing a ref to the keyfile might give developers a new and unexpected memory overhead compared to the current GDesktopAppInfo.

We could make it a bit more light if one specifies a set of properties to extract from the keyfile and then have those retrievable via a g_desktop_app_info_get_key(appinfo, key_name), but that seems like an overly complex solution.

For my case at least, if there just was a set_id() method then I could mix and match the extra properties to the right ids myself. Less elegant, but could work.

Another solution that I examined was to simply have a custom subclass of GDesktopAppInfo that does what I need, but it doesn't look like gdai supports standard GObject construction so subclassing can not work afaik?
Comment 6 GNOME Infrastructure Team 2018-05-24 12:41:40 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/335.