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 762206 - apps-menu broken with alternate AppDir
apps-menu broken with alternate AppDir
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: extensions
3.14.x
Other Windows
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2016-02-17 17:51 UTC by Vitaly S
Modified: 2016-07-12 23:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
app: Add a construct-only app-info property (3.25 KB, patch)
2016-07-11 16:45 UTC, Florian Müllner
none Details | Review
apps-menu: Handle .desktop files from non-standard directories (1.29 KB, patch)
2016-07-11 16:45 UTC, Florian Müllner
committed Details | Review
app: Add a construct-only app-info property (3.82 KB, patch)
2016-07-12 18:55 UTC, Florian Müllner
committed Details | Review

Description Vitaly S 2016-02-17 17:51:52 UTC
I have a custom menu that specifies an alternate location of the *.desktop files using the <AppDir> directive in the menu XML file.

This causes gnome classic menu to throw errors similar to the one reported in bug #759004:

Feb 16 19:36:30 sandbox04 gnome-session[61095]: (gnome-shell:1549): Gjs-WARNING **: JS ERROR: TypeError: b is null

I believe the cause is that inside the apps-menu extension, it calls:

entry = iter.get_entry()
app = appSys.lookup_app(entry.get_desktop_file_id())

However entry.get_desktop_file_id() only returns the basename of the desktop file, and appSys.lookup_app doesn't find it in the standard locations (/usr/share/applications, ~/.local/share/applications) because it's in a different location specified by AppDir. And appSys doesn't appear to have a method to load a desktop file using an absolute path (this feature was removed in #698486).

Please let me know how we can get gnome apps-menu extension working with an alternate AppDir. The reason for using an alternate AppDir is that we have centralized menus that are shared with multiple users using an NFS path.
Comment 1 Jasper St. Pierre (not reading bugmail) 2016-02-17 18:01:57 UTC
Put your NFS mount as a folder inside /usr/share/applications/, perhaps. Or create a /opt/nfs-mount/share/applications and set XDG_DATA_DIRS.

We're moving away from menu files across the desktop, since not every component that wants to launch other applications (for MIME types or URI handlers) should need to read a .menu file -- since that file is actually quite expensive to read.
Comment 2 Florian Müllner 2016-07-11 16:44:52 UTC
I'll attach a downstream fix for discussion - IMHO it's valid to not parse .menu files all over the place, but at least the component that is supposed to display applications according to that file (i.e. the apps menu) should not choke on it, even when those apps will not quite work as expected (icon/name in top bar, add to favorites in dash, open with ... in file manager etc.).
Comment 3 Florian Müllner 2016-07-11 16:45:15 UTC
Created attachment 331241 [details] [review]
app: Add a construct-only app-info property

This will allow us to create a ShellApp from JS code, for instance
for .desktop files that aren't known to the AppSystem.
Comment 4 Florian Müllner 2016-07-11 16:45:32 UTC
Created attachment 331242 [details] [review]
apps-menu: Handle .desktop files from non-standard directories

.desktop files in non-standard locations are not handled by GIO,
so looking up apps for entries for such locations (e.g. a
directory added via the AppsDir directive) will fail. We can
still handle this case in the menu by creating the app directly
from the entry's AppInfo.
Comment 5 Ray Strode [halfline] 2016-07-12 18:22:06 UTC
Review of attachment 331241 [details] [review]:

::: src/shell-app.c
@@ +161,3 @@
+    {
+    case PROP_APP_INFO:
+      _shell_app_set_app_info (app, g_value_get_object (value));

Since this is a CONSTRUCT_ONLY property, set_app_info needs to handle getting passed a NULL value (if the caller didn't pass 'app-info' in the initial property list).
Comment 6 Florian Müllner 2016-07-12 18:55:23 UTC
Created attachment 331375 [details] [review]
app: Add a construct-only app-info property

Fixed.
Comment 7 Ray Strode [halfline] 2016-07-12 19:40:00 UTC
Review of attachment 331375 [details] [review]:

++
Comment 8 Ray Strode [halfline] 2016-07-12 19:40:29 UTC
Review of attachment 331242 [details] [review]:

++
Comment 9 Florian Müllner 2016-07-12 23:28:38 UTC
Comment on attachment 331375 [details] [review]
app: Add a construct-only app-info property

Attachment 331375 [details] pushed as 2f0039e - app: Add a construct-only app-info property
Comment 10 Florian Müllner 2016-07-12 23:29:19 UTC
Attachment 331242 [details] pushed as a35336d - apps-menu: Handle .desktop files from non-standard directories