org.gnome.DiskUtility.desktop not executing "gnome-disks" executable through an App Launcher, yet using a custom gendesk .desktop file works fine, CLI as well works

[TeusLollo]

System

• xuname:
  Void 5.15.45_1 x86_64 GenuineIntel uptodate rFFFF
• package:
  gnome-disk-utility-41.0_1

Expected behavior

"org.gnome.DiskUtility.desktop" file located into "/usr/share/applications" should execute the "gnome-disks" executable when selected through a given App Launcher Application compatible with freedesktop.org specifications, thus launching the Gnome-Disks App.

Actual behavior

"org.gnome.DiskUtility.desktop" file located into "/usr/share/applications" fails completely with no error messages when selected into a given App Launcher Application ("wofi" in my current case, with "sway" WM).

Yet, executing the "gnome-disks" executable through CLI works perfectly, and the App itself works perfectly too.

Also, I went ahead, and utilized "gendesk" to create a custom .desktop file which I put into "~/local/share/applications". I can confirm that such a custom .desktop file WORKS perfectly, and have in fact been using it for a few months already (Hence why I forgot to report before).

Code of MY custom .desktop file, created through "gendesk", and located into "~/local/share/applications", is as follows:

[Desktop Entry]
Version=1.0
Type=Application
Name=Disks-Gnome
Comment=Disks-Gnome
Exec=gnome-disks
Icon=/home/username/.local/share/applications/FlatDisks.png
Terminal=false
StartupNotify=false
Categories=Application;

My custom .desktop file, aside from missing localization tags, also misses the "DBusActivatable=true" parameter which I found into "org.gnome.DiskUtility.desktop" file located into "/usr/share/applications", yet I presume this is not very relevant to the issue at hand.

This has been happening for a few months already (My custom .desktop works fine, thus I forgot to report in the meantime), and has been happening on three separate machines to boot, all with manual install only. App Launcher is currently "wofi" with "sway" WM, but months ago I also saw this happening with "rofi", on "openbox" WM.

Steps to reproduce the behavior

Simply select the "org.gnome.DiskUtility.desktop" (Tag-named to "Disks" if App Launcher can read such tags, and is configured to do so) into a given freedesktop.org-compatible App Launcher (This has been happening both with "wofi" and "rofi" on me), and it will NOT execute the "gnome-disks" executable, thus NOT launching the Gnome-Disks App.

However, executing "gnome-disks" through the CLI, or otherwise utilizing a custom .desktop file created through "gendesk" as mentioned above, both launch the App just fine.

Maybe some post-install MIME update is missing? This has been happening also on a very recent (Less than 4 weeks) manual Void Install.

[paper42]

Could you test if you can still reproduce this issue with gnome-disks-utility 42.0?

[TeusLollo]

@paper42
Here's the report:

1. Yes, the issue still appears identically with package gnome-disk-utility-42.0_1 installed

2. The solution I provided above (Custom .desktop file, created through "gendesk", and located into "~/local/share/applications") still works perfectly

3. There was NOT a need to rebuild such custom .desktop file. The latter has been working with both the previous and the current gnome-disk-utility package versions with NO modifications/rebuilds whatsoever

4. Everything stated above in the bug report is still valid. Only thing which has changed was the package update to gnome-disk-utility-42.0_1 (Aside from further updates of dependencies/unrelated packages in the meantime, of course)

5. I can testify that the gnome-disk-utility app (Aside from what is mentioned in the bug report, of course) otherwise works perfectly

Thanks for your concern.

[paper42]

I can not reproduce this, dex /usr/share/applications/org.gnome.DiskUtility.desktop runs fine, desktop-file-validate /usr/share/applications/org.gnome.DiskUtility.desktop is clean and running Disks with wofi --show drun also works fine.

[TeusLollo]

Output of wofi --show drun /usr/share/applications/org.gnome.DiskUtility.desktop :

/usr/share/applications/org.gnome.DiskUtility.desktop cannot be executed: Message recipient disconnected from message bus without replying

Weird.

Custom gendesk .desktop file works instead, which would exclude missing dependencies/configuration woes.

[paper42]

from https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html:

DbusActivatable: A boolean value specifying if D-Bus activation is supported for this application. If this key is missing, the default value is false. If the value is true then implementations should ignore the Exec key and send a D-Bus message to launch the application. See D-Bus Activation for more information on how this works. Applications should still include Exec= lines in their desktop files for compatibility with implementations that do not understand the DBusActivatable key.

It seems like your system is missing the dbus user session, but wofi tries to launch gnome-disks with a dbus message.
I think this is a bug in wofi - wofi should fall back to just running Exec when the dbus user session is not available.

[TeusLollo]

This gets even weirder.

I added the DBusActivatable=true parameter to my custom gendesk .desktop file, just to see if it would force wofi to start, and possibly fail, a dbus session.
But NO, the custom gendesk .desktop file STILL works fine, wofi --show drun reports NO error either.

I mean, the only relevant difference between package .desktop file, and custom .desktop file, are the DBusActivatable=true parameter, localization tags, and different directory locations.

I'm at loss here. Using dbus-elogind-1.12.20_1 package, btw. It can't be a missing dependency and/or misconfiguration, since the custom .desktop file works fine. Weird.

[TeusLollo]

Also, output of dbus-run-session gnome-disks

dbus-daemon[6952]: [session uid=1000 pid=6952] Activating service name='org.gtk.vfs.Daemon' requested by ':1.0' (uid=1000 pid=6953 comm="gnome-disks ")
dbus-daemon[6952]: [session uid=1000 pid=6952] Successfully activated service 'org.gtk.vfs.Daemon'
fusermount3: failed to access mountpoint /run/user/1000/gvfs: Permission denied
dbus-daemon[6952]: [session uid=1000 pid=6952] Activating service name='org.a11y.Bus' requested by ':1.2' (uid=1000 pid=6953 comm="gnome-disks ")
dbus-daemon[6952]: [session uid=1000 pid=6952] Successfully activated service 'org.a11y.Bus'
dbus-daemon[6971]: Activating service name='org.a11y.atspi.Registry' requested by ':1.0' (uid=1000 pid=6953 comm="gnome-disks ")
dbus-daemon[6971]: Successfully activated service 'org.a11y.atspi.Registry'
SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry

The App works fine given this output, btw.

Thanks for your concerns.

[TeusLollo]

I noticed you may have deleted a comment (Mentioning .xinitrc, which of course is not relevant with sway WM).

I just wanted to confirm however that yes, sway WM is launched with those, along with further, parameters:

export XDG_SESSION_TYPE=wayland
export XDG_SESSION_DESKTOP=sway
export XDG_CURRENT_DESKTOP=sway
export LIBSEAT_BACKEN=logind

exec dbus-run-session sway

[paper42]

From the wofi readme:

drun and dbus

Some desktop files declare themselves as being launched by dbus, if this is the case wofi can experience issues on systems where a user session bus is not automatically started such as systems using elogind.

To manually launch a user session bus run the following:

dbus-daemon --session --address=unix:path=$XDG_RUNTIME_DIR/bus

could you try a different launcher like dex?

dex /usr/share/applications/org.gnome.DiskUtility.desktop

[TeusLollo]

First of all, sorry for taking a long time, but I was away from my void boxes today.

Here's the report:

1. Yep, dex /usr/share/applications/org.gnome.DiskUtility.desktop works perfectly, which circumscribes the problem to a wofi bug? | lack of feature?

2. Not sure why other void users never noticed this bug though. Maybe usage of WMs instead of DEs is not that common, especially on wayland?

3. Not sure if this should be reported to https://todo.sr.ht/~scoopta/wofi since the wofi readme already remarks wofi "can experience issues on systems where a user session bus is not automatically started such as systems using elogind". Seems they're aware of this.

4. Maybe something about this should be mentioned into the "Session and Seat Management" of the void handbook? As is "If you're having problems running .desktop files with elogind on wayland, try using gendesk and a custom local path to a .desktop file"?

You're the boss, you decide. Kinda funny this story though. I really think however the workaround with gendesk and the custom .desktop file should go into a manual somewhere.

[paper42]

I don't think we can do anything with this, this seems to be an upstream wofi issue.

[bileslav]

@TeusLollo, here's the missing part:

dbus-update-activation-environment DISPLAY WAYLAND_DISPLAY XDG_CURRENT_DESKTOP

It should be executed after those variables initialized, e.g. inside ~/.config/river/init in my case.

[TeusLollo]

@TeusLollo, here's the missing part:

dbus-update-activation-environment DISPLAY WAYLAND_DISPLAY XDG_CURRENT_DESKTOP

It should be executed after those variables initialized, e.g. inside ~/.config/river/init in my case.

Indeed.
I came across the whole DISPLAY mojo later when I also came across this other issue: https://bbs.archlinux.org/viewtopic.php?id=191251

I actually run:

exec dbus-run-session sway
exec dbus-update-activation-environment DISPLAY XAUTHORITY WAYLAND_DISPLAY XDG_CURRENT_DESKTOP

In a custom script to start the sway WM.

I specifically did that to solve the [Gtk-WARNING **: cannot open display] , but I had not connected the dots that this would also solve the whole wofi issue. This still does not explain why using gendesk worked as a workaround, but I digress.

So, to anyone looking to utilize custom WMs, remember to run somewhere:

exec dbus-update-activation-environment DISPLAY XAUTHORITY WAYLAND_DISPLAY XDG_CURRENT_DESKTOP

After your WM wayland session has begun through a dbus-run-session command.