Find qdbus command correctly
Needs ReviewPublic

Authored by ngraham on Dec 11 2019, 12:53 PM.

Details

Reviewers
davidedmundson
Group Reviewers
Spectacle
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.

BUG: 413007
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

Diff Detail

Repository
R166 Spectacle
Branch
find-qdbus-correctly (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 20321
Build 20339: arc lint + arc unit
ngraham created this revision.Dec 11 2019, 12:53 PM
Restricted Application added a project: Spectacle. · View Herald TranscriptDec 11 2019, 12:53 PM
ngraham requested review of this revision.Dec 11 2019, 12:53 PM
davidre added a subscriber: davidre.EditedDec 11 2019, 12:57 PM

Hmm that requires that we have qtpaths at build time which is for example shipped in qttools5-dev-tools. And that between build system and run time qdbus is in the same location. Is that an assumption we can make? I'm not an expert but I think there is never a case where you would compile on one distro and then try to run it on another?

Right, I don't think that's ever expected to work.

fvogt added a subscriber: fvogt.Dec 11 2019, 1:07 PM

the actual name of the command is qdbus-qt<version> in the distro's Qt

Just qdbus, no -qt5 suffix in the Qt binaries dir

CMakeLists.txt
117

qtpaths might not be in $PATH either, and if it is, might not be one matching the Qt version it's currently building against...

Looking at Qt CMake module code, it seems like that is hardcoded in there during build... Maybe changing the last component of Qt5::qmake's imported path (if that's even possible) to qdbus would work.

The best possible way of course would be that we support activating desktop actions via dbus and do so in kglobalaccel:
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus

ngraham updated this revision to Diff 71271.Dec 11 2019, 1:17 PM
ngraham marked an inline comment as done.

Find the Qt binaries dir in a safer way

ngraham edited the summary of this revision. (Show Details)Dec 11 2019, 1:17 PM
ngraham edited the summary of this revision. (Show Details)Dec 11 2019, 1:29 PM
kossebau added inline comments.
CMakeLists.txt
42

ECMQueryQmake is not part of the official API of ECM though, so you first want to make that one public.

ngraham added inline comments.Dec 12 2019, 10:33 AM
CMakeLists.txt
42

I don't know what this entails and what the consequences would be. Can you explain? Or maybe show me how? Or do it yourself? ;)

fvogt added a comment.Dec 12 2019, 7:03 PM

I'm wondering whether this might not actually break the "qtchooser" variant - if binaries are in a Qt version specific dir, the path to qdbus would no longer exist after a Qt update without a rebuild of spectacle.

The Qt binaries dir is only versioned for major versions (4, 5, 6) so the path does not become invalid when you upgrade minor Qt versions.

ngraham edited the test plan for this revision. (Show Details)Dec 12 2019, 8:38 PM

What is the path forward here?

@kossebau Ping regarding the requested changes to the macro.

rdieter added a subscriber: rdieter.Mon, Jan 6, 4:39 PM

Looking at the actual code being touched here: Is qdbus actually a good choice here? Can it be expected to be installed by default? Would dbus-send not be the better option, as it seems part of the normal D-Bus demon implementation package?

The approach taken here, having desktop files sending commands to a D-Bus service makes me wonder if this should not be standardized in some way by xdg. Are there similar usages?

It feels strange to me to rely on separate random D-Bus sending tool incarnations, instead of e.g. having the menu listing the entry derived from the desktop file sending such D-Bus messages directly. Also seeing nothing which relates to the desktop file specified D-Bus Activation makes me wonder if this was designed without knowing about that one, or whether that one should be reworked/improved in the specification to cover the use case of spectacle (whatever it is, have not tracked).

CMakeLists.txt
42

I am not aware of ecm contribution guides, but whenever I added something, I took conclusion from the patterns found in the existing official module files, like

  • have a documentation header in restructuredtext format
  • have the documentation linked from a file in docs/
  • be self-sufficient (like, make sure all deps are included)
  • have some unit tests

Sorry, no time here to take over such work.

I tried dbus-send in D25293 but it was impossible to make work (@davidedmundson and I spent an afternoon on it unsuccessfully). qdbus seems like the only practical option unless we want to re-engineer everything. While that's possible, and maybe desirable long-term it seems like overkill to me for fixing this fairly simple bug.

I guess I'll take a look at making ECMQueryQmake public.

Do I correctly understand from the previous patches that spectacle should now be single instance application? In that case it might really make more sense to investigate to use the official D-Bus Activation part of the desktop file specification instead of manual D-Bus message sending hackery. That part had been designed for such use cases from what I can tell.

Do I correctly understand from the previous patches that spectacle should now be single instance application? In that case it might really make more sense to investigate to use the official D-Bus Activation part of the desktop file specification instead of manual D-Bus message sending hackery. That part had been designed for such use cases from what I can tell.

That however needs support in kglobalaccel and whatever handels jumplist actions right? Maybe you could add your thoughts to T12063 and/or T2050

BTW, not invoking yet another process with the qdbus executable, but instead sending off the D-Bus message drectly might also increase reaction time.

So instead of investing time & work of yours & reviewers into extending the official API of ECM (which then also needs to be maintained in the future) it would be better to invest the time & work directly into the properly designed solution.

You're probably right, but this DBus activation stuff is way over my head. Someone else is probably going to need to take the lead on it, if it's the right way to go.

That however needs support in kglobalaccel and whatever handels jumplist actions right? Maybe you could add your thoughts to T12063 and/or T2050

Perhaps I was also over-optimistic about KDE, being the one who once took the lead with DCOP, had full implementation of anything D-Bus... But grepping for DBusActivatable on lxr.kde.org makes me feel like perhaps I only ever read the spec, never saw actual code in Plasma/KF :/

So perhaps the current hack has to be maintained then for now still, meh.

This needs someone from Plasma team to pick up though and thus do related comments on tasks etc, no time for me in 2020 to think about Plasma stuff.

ngraham added a subscriber: Plasma.Wed, Jan 8, 6:17 PM