Couple of nitpicks, feel free to ignore

Oh wow, silly me. Shipit!

I guess? Note that I authored this diff :)

@davidre, does this look good to you?

remove unused variable

In D22074#598803, @dporobic wrote:

All commits for kColorPicker:

kColorPicker.tar.gz39 KBDownload

Meanwhile there have been some updates to kImageAnnotator, maybe you want to add them too, even tough some unit tests are currently broken, I need to fix them, so potentially more commits coming.

kImageAnnotator-latest.tar.gz57 KBDownload

I'm closing this issue for now because from my point of view the core issue seems to be sufficiently dealt with.

@ngraham please see to it that ECMQueryQMake becomes public in ECM. Specifically remove the comment about it not being public and add proper documentation sugar to the file (see other modules for example I guess).

It's harder to fix because on 19.12 we save not the last capture mode but the index of the combobox which doesn't map directly to the capture mode. And I don't want to change what's being saved in the config on stable or duplicate the combobox mapping here (which also is broken) so I will push this only to master

Whoops I say fixed-in 19.12.2 but that patch is only against master. That bug is probably also in stable and here it comes from straight porting. I will look into it and also submit a patch for 19.12

Remove unrelated change

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?

Rebase

All commits for kColorPicker:

In D22074#598636, @dporobic wrote:

Whats the process for adding new Widgets to KWidgetsAddons?

Whats the process for adding new Widgets to KWidgetsAddons?

It seems to me that KColorPicker has not been pushed into KWidgetsAddons until now. Maybe it would also help to port KImageAnnotator to make use of KColorButton instead which is already included in the widgets?
As I am no developer I am not sure if this could help but it seems to me that this dependency/build problem is the last piece left before it could be shipped, right?

scheme().isEmpty()

This breaks saving screenshots with keyboard shortcuts.

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

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.

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

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.

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.

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.

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?

@kossebau Ping regarding the requested changes to the macro.

Closed in favor of adding FileManager1 dbus interface to Krusader

In D23316#585442, @ltoscano wrote:

In D23316#583552, @davidre wrote:

Landing it now - it's after christmas and I should have time in the next days/week to fix issues that we find.

But then the commit message is incorrect, as it's not FIXED-IN 19.12.

I pushed a few follow-up fixes to the strings introduced by this change here: https://commits.kde.org/spectacle/befcb1748b2a770bce28d3aed0f0b4addd06d622

In D23316#583552, @davidre wrote:

Landing it now - it's after christmas and I should have time in the next days/week to fix issues that we find.

Rebase

What is the path forward here?

Landing it now - it's after christmas and I should have time in the next days/week to fix issues that we find.

In D23316#580173, @davidre wrote:

Is there a way we can move forwards? Do other Applications that use KConfigDialog exhibit this problem, too? If yes maybe it's something to improve at that level. If not we can have a look what they do.
https://lxr.kde.org/ident?_i=KConfigDialog
For example in Okular I even get scrollbars with default settings.

With empty spectaclerc it is fine. I forget to keep my original rc file. Probably have a back up in my external drive. Will let you know when I get the backup.

In D23316#580467, @guoyunhe wrote:

Saving option is broken on my system. Clicking "Save" button throws error "Invalid file name". The default pattern is not saved. I have to go to configuration dialog and click "OK" to save the file name pattern

Do you mean it's not saved in the config file? That's fine, the generated code doesn't write default values to the config file.
I can't reproduce the error with an empty or my spectaclerc. Can you reproduce it? With you current config file or with a new one? If yes, what's your value of saveFilenameFormat?

The default format combobox shows "BMP". But it was "PNG" before. For screenshots, I think "PNG" and "JPEG" are enough. More options bring confusion.

That's because I changed the key in the config file. See the update script

Saving option is broken on my system. Clicking "Save" button throws error "Invalid file name". The default pattern is not saved. I have to go to configuration dialog and click "OK" to save the file name pattern.

Look good in openSUSE:

Is there a way we can move forwards? Do other Applications that use KConfigDialog exhibit this problem, too? If yes maybe it's something to improve at that level. If not we can have a look what they do.
https://lxr.kde.org/ident?_i=KConfigDialog
For example in Okular I even get scrollbars with default settings.

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.

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:
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus

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? 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?

Found a better way that doesn't involve going insane trying to make dbus-send work: D25883

In D23316#573074, @davidre wrote:

Youre font seems bolder? Anyways we can easily increase the height.

Rebase once more

In D23316#572942, @ngraham wrote:

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:

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.

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?

Nice catch.

rebase

Need a bit more height

Correctly read default value dependent on another config entry

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
D23316

Also use enum for the last selected captureMode

• Fix typo in update file

LGTM, I'd still aim for the .ui port as a second step though.

address comments

In D23316#564185, @ngraham wrote:

In D23316#563932, @ervin wrote:

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.

If we have to port it to anything, I'd prefer a QML-based UI rather than making new .ui files.

In D23316#563932, @ervin wrote:

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.