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.
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.
Wed, Dec 11
Find the Qt binaries dir in a safer way
The best possible way of course would be that we support activating desktop actions via dbus and do so in kglobalaccel:
the actual name of the command is qdbus-qt<version> in the distro's Qt
Right, I don't think that's ever expected to work.
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?
Found a better way that doesn't involve going insane trying to make dbus-send work: D25883
Mon, Dec 9
Fri, Dec 6
Rebase once more
I still think this a cool feature, but I have the feeling this can be done in a much shorter patch. This seems to me a bit like overkill. Would be awesome if maybe somebody else could weigh in.
Thu, Dec 5
All functionality works perfectly for me. However this regressed the default width of the settings window. Not it's not wide enough to accommodate all controls without an ugly horizontal scrollbar:
@davidre, is this okay now?
Need a bit more height
Tue, Nov 26
Correctly read default value dependent on another config entry
Fri, Nov 22
Yeah, look exactly the same, maybe yours is better (with configuration update script). We can close this one when yours get accepted.
I added a similar fix earlier today to
Also use enum for the last selected captureMode
Thu, Nov 21
- Fix typo in update file
LGTM, I'd still aim for the .ui port as a second step though.
Mon, Nov 18
Looks good to me regarding the kconfig_compiler use (epsilon one key which would be better suited to an enum).
The next natural step would be to switch the dialog pages to ui files, that would remove some more code.
Thu, Nov 14
Yeah, now that you mention it, I notice that too.
I don't know but KGlobalAccel uses KLauncher to execute the command found in the Exec line of the desktop file.
However I noticed something weird when manually using your dbus-send commands. dbus-send --session --dest='org.kde.Spectacle' --type=method_call '/' 'org.kde.Spectacle.StartAgent' only seemed to work every second time.
Maybe we can do this for 20.03 with 19.12 now branched. This would leave us some time to test it. What do you think @ngraham?
Sorry, it doesn't work for me either. I didn't relog before testing and I guess it was still using the qdbus commands. KLauncher gets the right arguments I think:
It doesn't seem to work here either, but adding the --print-reply argument helps for some reason.