wf-panel doesn't seem to open certain apps

[tyressk]

Certain apps like cheese, font-manager, gnome-text-editor don't open from the wf-panel menu with no error or warning. Running the .desktop files directly with gio launch works. No luck yet figuring during debugging but common denominator seems to be gtk(3?). Tested on another launcher (nwg-drawer) and these .desktop files work as well.

Tested with fresh .ini files for both wf-shell and wayfire.

version: 0.8.1-6 Arch AUR

[trigg]

I've been unable to replicate these issues, same version of package from AUR.

Looking at the .desktop file for these, it seems they all specify StartupNotify=true

It might be worth checking if this link exists by running grep -Rnw '/usr/share/applications' -e 'StartupNotify=true' and seeing if the list of files covers all of the programs that won't run.

If the list of Gtk apps that specify StartupNotify and the list of apps that won't run are equal, this might potentially be a dbus issue.

[tyressk]

@trigg thanks for taking a look. So, grep -Rnw '/usr/share/applications' -e 'StartupNotify=true' shows many apps that do work. However, going from your lead that it may be a dbus issue, using grep -Rnw '/usr/share/applications' -e 'DBusActivatable=true' shows a 1-is-to-1 list of apps I can't run.

I found the dbus services files in /usr/share/dbus-1/services/, and for example cheese has this entry:

[D-BUS Service]
Name=org.gnome.Cheese
Exec=/usr/bin/cheese --gapplication-service

and running any of the exec statements for these files (e.g. /usr/bin/cheese --gapplication-service) do not work

I also now found Failed to start Portal service (GTK/GNOME implementation). in my journalctl. I'll investigate more in a bit, but it seems like a portal issue

[marcusbritanicus]

LXQt had faced a similar issue. Few users were unable to start DbusActivatable apps from the menu unless DbusActivatable was set to false. The issue was fixed in LXQt. Perhaps, you might find something interesting in one of the PRs linked there.

Edit:
I think, currently we're simply using the Exec key to start any given app. Desktop entry spec from Xdg state that one should ignore the Exec key if DbusActivatable is set to true. In such cases, we should start the app using dbus.

Cc: @soreau

[tyressk]

@marcusbritanicus thanks for the info and link. So I tried to set DBusActivatable=false on one of the .desktop files and it worked so it seems it's up to spec and not using the exec key when that flag is true.

Based on the thread you linked it seems like the LXQt people gave in and merged an exec fallback here so that if dbus fails it runs the exec line.

[marcusbritanicus]

@tyressk While I'm not very sure, one thing you might be able to do instead of editing the desktop files in /use/share/applications is copy the offending desktop to ~/.local/share/applications and do your edits. Then you'll not have to worry about the desktop being overwritten during upgrades.

[trigg]

While I'm not very sure,

I am. This is absolutely what you should be doing to keep local edits of .desktop files.

I have a helper script I use to remove launchers I don't use here, which works on this premise..

[tyressk]

Thanks for your responses @marcusbritanicus and @trigg . I only temporarily edited the .desktop file and put them back. I might actually end up copying them to my ~/.local/share/applications like you both mentioned (I also keep some wonky electron .desktop files there where I put the wayland flags on). I'll still try to figure out why I can't run these DBusActivatable apps, and then comment on this issue if I get them to work!

[trigg]

I'd advise double-checking your wayfire settings as per this segment of the wiki

[tyressk]

@trigg this worked for me!

Gtk+3 applications slow startup

This is due to GTK+ waiting for xdg-desktop-portal to start via D-Bus. This times out because the D-Bus activated service doesn't know what WAYLAND_DISPLAY to connect to. Add the following to your configuration file:

[autostart]
0_environment = dbus-update-activation-environment --systemd WAYLAND_DISPLAY DISPLAY XAUTHORITY

I actually ignored this part in the beginning because I didn't notice Gtk apps being slow, plus I had also removed xdg-desktop-portal while I was debugging. Thanks!

Edit: Wonder if the wiki needs to be updated to include this issue as well?

[ammen99]

Edit: Wonder if the wiki needs to be updated to include this issue as well?

Feel free to add more information to the wiki if you think it needs to cover more :) But I wouldn't link directly to this issue, better describe with words in what other ways the issue can manifest as.