| Summary: | Desktop file assumes `qdbus` is the name of the command | ||
|---|---|---|---|
| Product: | [Applications] Spectacle | Reporter: | Nate Graham <nate> |
| Component: | General | Assignee: | Boudhayan Gupta <me> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | fabian, kde, kde, kde, lbeltrame, rdieter |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/spectacle/8822c250121291bc01f027fa20a1e17a544a9d04 | Version Fixed In: | 20.04.0 |
| Sentry Crash Report: | |||
|
Description
Nate Graham
2019-10-15 22:07:32 UTC
(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. 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 |