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.

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

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

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.

What is the path forward here?

@kossebau Ping regarding the requested changes to the macro.

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).

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.

In D25883#590433, @kossebau wrote:

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.

In D25883#590441, @davidre wrote:

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.

I don't think I have the skills to rewrite the whole dbus activation stuff from scratch. If nobody else has the bandwidth to do that, can we just land this as a flawed-but-reasonable solution to the problem?