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.

Yeah, now that you mention it, I notice that too.

In D25293#562511, @ngraham wrote:

In D25293#562309, @davidre wrote:

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:

What does this mean? Sorry, I'm pretty new to dbus.

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.

In D25293#562309, @davidre wrote:

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:

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.

In D25293#562192, @davidre wrote:

Shortcuts work for me. For testing make sure to install to /usr

Shortcuts work for me. For testing make sure to install to /usr since we link our .desktop from KDE_INSTALL_FULL_APPDIR to the kglobalaccel one.

Use real file

Rebase

add comment

All right, fair enough! Let's maybe add some comments explaining the reason for the event handler, then ship it.

In D24508#544318, @ngraham wrote:

This works, though I'll admit that the custom event filter makes me a bit queasy. Feels kind of like hacking around something that wasn't implemented the right way in the first place (i.e. using a QDialog and QDialogButtonBox). Is porting away from that stuff even worse?

I tried making it a QWidget but then no button was reacting to enter and we would lose close-on-esc which we would then have to implement ourselves. Hey it's, not *that* bad ;). It's an only an handler and not a filter for another widget.
Maybe someone with more experience has another idea? Or we concede that no button can be activated with Enter only with Space.

Also is there a reason why we can't use only PushButtons in the main window? I was surprised to discover that half of them were ToolButtons when I went digging into the code, because they all *look* like PushButtons.

I didn't wrote the code but the obvious reason would be that one can assign actions to ToolButtons. Here it is used with KStandardActions and I use it for the screenshot button to switch easily between states.

This works, though I'll admit that the custom event filter makes me a bit queasy. Feels kind of like hacking around something that wasn't implemented the right way in the first place (i.e. using a QDialog and QDialogButtonBox). Is porting away from that stuff even worse? Also is there a reason why we can't use only PushButtons in the main window? I was surprised to discover that half of them were ToolButtons when I went digging into the code, because they all *look* like PushButtons.

remove stray qdebug

Works fine. All buttons get proper focus on TAB now.

The slider knob does not scale with bigger font sizes and I couldn't find an easy solution for that. Is there one?

Thanks for the patch! This is a nice complement to the Gwenview one (D24309) to make these user interfaces more consistent.

Also we are not in a situation where we have that many backends where there would be a significant impact on executable size

My initial thoughts (I was on vacation): Is there really an advantage in using shared libs? You claim it reduces overhead but I don't see in which way. Instead there is a performance penalty in using dynamic libraries compared to having all the code in one binary. Also we are not in a situation where we have that many backends where there would be a significant impact on executable size. Neither do we support a a public plugin framework where one could install third party plugins.
I see no point in this, sorry.

In D23446#537268, @Leon0402 wrote:

I can build it, but when I run spectacle - I get a segmentation fault. Has anyone else such a problem?
The problem seems to be in the setupShortcuts().

ofc, i commented it out just to see if it would run at all.

I'm also not experiencing this issue. Do you have the problem if you put "setupShortcuts()" to it's old position? And perhaps you could find out where execactly the setupShortcuts() method causes the problem? Maybe this gives us some hint, what might be wrong.
Obviously, if anybody else can confirm the problem that would be super helpful.

I can build it, but when I run spectacle - I get a segmentation fault. Has anyone else such a problem?
The problem seems to be in the setupShortcuts().

ofc, i commented it out just to see if it would run at all.

I don't get a crash. The UI and behavior look fine to me, as does the code. But I'd really like a thorough code review from @davidre or someone else before we land this. I suspect he is on vacation or something. Anyone else can of course also review. :)

In D23446#536356, @Leon0402 wrote:

Anyone, who can review this?

Nah let's do it.

Hi there,

• Fixs to CMakeLists

• Added CaptureMode Rectangular Region
• Moved code to determine wether the "Current Screen" CaptureMode should be shown to the comboBox
• ComboxBox and shutter options update, when the backend changes
• Fixed a few bugs
• Only uses one enum now called CaptureMode, instead of two very similar enums

Anyone, who can review this?

Is there something holding this back to land?

Maybe this is relevant: https://lists.qt-project.org/pipermail/development/2019-September/037434.html

• Use dynamic plugins instead of static plugins
• Changed CMakeLists, so plugins will be compiled to shared libs (dymanic plugins)
• Use json metadata
• Improved auto selection algorithm (added "recommended" field in .json, so the algo knows, which plugin should be preferred)
• Added runtime checks, so the plugins can check whether all requirements are fullfilled (for example if kwin is available)
• plugins are unloaded automatically if not needed (instead of install/remove button)
• Fixed some Bugs

In D24034#533586, @thiago wrote:

This really needs to be fixed in Qt. 5.13.1 has an overhaul of the system, please make sure that the patch is still required there and does not make things worse.

And please report positioning issues that you can reproduce in https://bugreports.qt.io/browse/QTBUG-77086

This really needs to be fixed in Qt. 5.13.1 has an overhaul of the system, please make sure that the patch is still required there and does not make things worse.

Nice! The code change seems same given the bug we're working around, and this doesn't seem to regress anything for me, but I can't test the fix since I don't have two high DPI screens. Hopefully someone with this kind of hardware can give the patch a whirl.

Better code style

...But is this true? the feature doesn't exist yet. We have no idea whether or not it would impose overhead on Spectacle when not in use. Maybe we should implement it before designing a feature to turn it off if it has bad performance. Who knows, maybe the performance turns out to be just fine! :) I honestly have no idea how the feature could possibly cause bad performance when it's not in use. "I want to turn it off because it has bad performance" smacks of a fixable design error that should be fixed, not worked around.

In D23932#530805, @Leon0402 wrote:

... for example a few people said, when I asked them in vdg if they would like screen record capabilities, that they don't because they don't need it and it's a significant overhead.

Anything requiring so technical an explanation of the options is certainly not something that should be in the UI.

That's unfair :D it's not a finished feature, it's wip , it was a technical analysis of scenarios, which should be taken into account and possible solutions (with the option to add some solutions from you or another). That doesn't make the setting complicated or anything for the user. I could explain every single revision I've done in such great detail ;)

Anything requiring so technical an explanation of the options is certainly not something that should be in the UI. :)

I see your points at @ngraham and @ndavis

Flexibility sounds good, but how am I supposed to know what I'm looking at or what options to pick? Perhaps it's better to handle the backends automatically, if possible?

Cool beans. I'm not sure this is something that should be exposed to the user in the settings window, though--a tleast not as currently presented. I can see people disabling things and breaking Spectacle.

In D23891#529990, @ngraham wrote:

Will revert.

We should consider renaming the enums or serialized values or adding a comment in the code though, because the way this is written is is confusing and looks wrong (even if it's right).

Will revert.

In D23891#529846, @davidre wrote:

Did you test this? I think the way it was was correct. A transient window is for example a popup . Only the popup is transientOnly (capturemode window under cursor) and everything is transientwithparent. See also the help text

-u, --windowundercursor    Capture the window currently under the cursor,
                             including parents of pop-up menus
  -t, --transientonly        Capture the window currently under the cursor,
                             excluding parents of pop-up menus

and the gui version
https://cgit.kde.org/spectacle.git/tree/src/Gui/KSWidget.cpp#n217

Please revert this

Did you test this? I think the way it was was correct. A transient window is for example a popup . Only the popup is transientOnly (capturemode window under cursor) and everything is transientwithparent. See also the help text

-u, --windowundercursor    Capture the window currently under the cursor,
                             including parents of pop-up menus
  -t, --transientonly        Capture the window currently under the cursor,
                             excluding parents of pop-up menus

and the gui version
https://cgit.kde.org/spectacle.git/tree/src/Gui/KSWidget.cpp#n217

Whoops.

Okay I changed it in Spectacle, so in the ComboBox, Spectacle shortcut settings, global settings it displays the correct string.

Updated capture/action names (and captureMode names in enum)

You don't need to change the translations; once you change the English string, the translators notice the change and begin to translate the new ones.

In D23446#526327, @ngraham wrote:

In D23446#526313, @Leon0402 wrote:

I would like this to be more consistent as well. I suppose the best wording would be
Capture entire screen
Capture current screen

What do you think?

That sounds just fine to me . And then in the combo box, you would omit the word "Capture" (it's implied).

In D23446#526313, @Leon0402 wrote:

I would like this to be more consistent as well. I suppose the best wording would be
Capture entire screen
Capture current screen

What do you think?

One important change with that version is that Fullscreen is called "Entire Desktop" instead.

Changed include order

• Improve code in various places
• Change model to QListModel
• Keep reference to QAction (so the texts can be updated if a shortcut changes)
• Add captureMode as a property of QAction (setData)

In D23723#525820, @davidre wrote:

This also applies the delay of 250 ms when saving the picture not only copying. To make this better we could move this either inside the if-else above or have another test if we copied to clipboard - can't get around a bit of duplication. However this piece of code is all over the place already and I don't like the design of forceNotify and quitting through the main window. So this if fine with me if we could avoid the extra wait when saving to a file.

Edit if and add else if

In D23446#525891, @Leon0402 wrote:

I'm not sure about the structure of the tableModel. Thinking about it we don't really have a table structure of items but a list. Also it seems you are mixing columns an roles. Your model advertises itself with 3 columns but only has data 2 and each column in a row refers to the same item.

I'm not quite sure what you mean with your last sentence, but in general I think a tableModel is suitable. It has three pieces of data each row. What exactly is done with it, how it is displayed in the end etc. has nothing to do with the model anymore in my opinion. I couldn't find an official statement about roles, but I liked this explanation from StackOverflow "A role is simply an additional selector used when accessing data of a model." -> So again I would say, each column could be accessed by a different role and displayed in a different way (or not displayed at all). For me three columns just means, each delegate uses three pieces of data and that's the case.
But anyway there is more than one way to go and I don't persist on using a tableModle, in fact, I'm totally fine with using a QAbstractListModel. Seems reasonable to me as well!

I'm also not that experienced in that area but in my mind you would use a tablemodel where you have items in table like structure and Roles to access different aspect of the items. So a list with multiple roles would fit here better.

hen introducing a TooltipRole to access the the tooltip through the index.

I'm not a fan of this though. It is not a tooltip (and would therefore confuse me to give it that role) and it will probably also not work as delegates come with code to display / use the data of the different roles automatically. So if you would set the toolTipRole and call the paint() method of the delegate, it would actually become (additionally) a tooltip.
Instead I would override QHash<int, QByteArray> QAbstractItemModel::roleNames() const and introduce a new UserRole "shortcutRole" or anything like that. I could also make a custom role for the action. It was confusing to me when I first saw the code, what that information is, because "Qt::UserRole" is not really descriptive. So I would suggest to also introduce a second custom role called "actionRole". This is not super important to me, I just think it would make the code a little bit more readable.

Would that be a good compromise? Would you leave the third data as Qt::UserRole or introduce a new role like ActionRole (as we override roleNames() anyways)

You're right of course, I was somehow thinking about tooltips when I meant shortcuts. Yes that would be the way for an additional role. You crename Qt::UserRole to give it a more descriptive name. Take a look here for example: https://cgit.kde.org/plasma-workspace.git/tree/wallpapers/image/backgroundlistmodel.h#n61/backgroundlistmodel.h#n61

I'm not sure about the structure of the tableModel. Thinking about it we don't really have a table structure of items but a list. Also it seems you are mixing columns an roles. Your model advertises itself with 3 columns but only has data 2 and each column in a row refers to the same item.

Changed if condition according to David's comment

I'm not sure about the structure of the tableModel. Thinking about it we don't really have a table structure of items but a list. Also it seems you are mixing columns an roles. Your model advertises itself with 3 columns but only has data 2 and each column in a row refers to the same item. So I would suggest switching to QAbstractListModel and then introducing a TooltipRole to access the the tooltip through the index.

This also applies the delay of 250 ms when saving the picture not only copying. To make this better we could move this either inside the if-else above or have another test if we copied to clipboard - can't get around a bit of duplication. However this piece of code is all over the place already and I don't like the design of forceNotify and quitting through the main window. So this if fine with me if we could avoid the extra wait when saving to a file.

@davidre, does this look good?