...But in openSUSE, it's `qdbus-qt5`. This means that if you compile Spectacle from source in openSUSE, the desktop file will reference a program that doesn't exist and fail. Presumably the openSUSE packagers are fixing this in their packaging, but it would be nicer to them--as well as support people who compile things from source--to programmatically generate the name of this command rather than hardcode it.
(In reply to Nate Graham from comment #0) > ...But in openSUSE, it's `qdbus-qt5`. (Nitpick) Not only on openSUSE, also on Arch (but qdbus exists for compatibility as well) and CentOS/Fedora, maybe others. There are a cases like this in plasma-workspace as well (wallpapers/image/wallpaper.knsrc and startkde/startplasma-wayland.cpp).
What is the canonical name of the command upstream? qdbus5 or qdbus?
er, qdbus-qt5 (or whatever)
(In reply to Nate Graham from comment #2) > What is the canonical name of the command upstream? qdbus5 or qdbus? IIRC neither. It's found in /usr/lib64/qt5/bin (whatever qtpaths(-qt5) --binaries-dir returns) as qdbus and most distros then symlink it into /usr/bin.
So maybe openSUSE should create a symlink so that referring to it as `qdbus` works. What do you think?
(In reply to Nate Graham from comment #5) > So maybe openSUSE should create a symlink so that referring to it as `qdbus` > works. What do you think? Won't work: The reason we have "qdbus-qt5" is that it does not conflict with Qt 4 (or Qt 6).
So how do other distros handle this?
(In reply to Nate Graham from comment #7) > So how do other distros handle this? Like we do, the places where Plasma relies on "qdbus" in $PATH are patched, like here for Fedora: https://src.fedoraproject.org/rpms/plasma-workspace/blob/c384afe59c056b1e3b522ac5ef030770388bf38f/f/startkde.patch#_57 It would be nicer if Plasma would not rely on qdbus in $PATH (which is a distro specific thing anyway, not done by Qt), but there are only very few places.
Ah, I see. So I guess we can make this nicer in Spectacle's cmake then.
Is using dbus-send a universal option?
(In reply to David Edmundson from comment #10) > Is using dbus-send a universal option? Here it's part of the same package as dbus-daemon, so probably yes.
Patch: https://phabricator.kde.org/D25293
Better patch: https://phabricator.kde.org/D25883
Git commit 8822c250121291bc01f027fa20a1e17a544a9d04 by Nate Graham. Committed on 06/02/2020 at 18:18. Pushed by ngraham into branch 'master'. Find qdbus command correctly Summary: Spectacle's Desktop file assumes that `qdbus` is in $PATH. However this is not guaranteed; the command lives in the Qt binaries dir which is not typically in $PATH, and distros typically create symlinks with different names in `/usr/bin`, but not all create a second compatibility symlink at `/usr/bin/qdbus` that points to the version for the current Qt version. Therefore, we should find the command in the Qt binaries dir itself rather than relying on these compatibility symlinks. FIXED-IN: 20.04.0 Test Plan: - Delete the `/usr/bin/qdbus` symlink, if you have one - Compile and install Spectacle - Hit PrintScreen - See that Spectacle still opens Reviewers: davidedmundson, #spectacle, sitter Reviewed By: sitter Subscribers: sitter, #plasma, rdieter, kossebau, fvogt, davidre Tags: #spectacle Differential Revision: https://phabricator.kde.org/D25883 M +4 -0 CMakeLists.txt M +2 -1 desktop/CMakeLists.txt R +5 -5 desktop/org.kde.spectacle.desktop.cmake [from: desktop/org.kde.spectacle.desktop - 097% similarity] https://commits.kde.org/spectacle/8822c250121291bc01f027fa20a1e17a544a9d04