Thanks

• Set a size for the dialog

The dialog still needs to be resized so every page fits if there is no way to do it automatically. Looking at Okular maybe not since it also has some scrollable pages?

• Install update file and make workaround work

In D23316#519796, @ngraham wrote:

• The settings window has some graphical glitches:
  

Whoops that was just for debugging

• All my settings were restored to their default value
• The Press Screenshot To radio button did not have a pre-selected value
• PNG images are huge again

Did you do the update? I think I need to still add the installation of it to the CmakeLists.txt

Move showInlineMessage back to private.

Rebase add autocopy and autosave

The initial idea to use the OSD Layer didn't work because the OSDs doesn't accept keyboard focus. Panel is still high enough and can be set to accept keyboard focus.

Thanks!

A few initial comments:

In D23446#519225, @Leon0402 wrote:

Personally, I find it a very useful feature too. Especially the argument of @felixernst that there is not really a point anymore in displaying the shortcut, if the user has changed them, is quite strong. In general, we can assume that users, who change the default shortcut, are then aware of their own shortcut they set (most likely these users are also power users). Still one could argue that it might be helpful for one shortcuts as well. So there would be the possibility to display only shortcuts up to a specific width. I would rather not this though, as such an approach is not straight forward to the user and might lead to confusion and bug reports.

I agree if the shortcut is displayed it should be displayed always. I noticed that your delegate doesn't implement sizeHintalthough we change the content being displayed.

To make that happen I would suggest the following changes:

• Change default Shortcut of rectangle to Alt + Print ... it's shorter (3 keys are just to long) and would fit with the task for new shortcut as the copy variant could be named then Ctrl + Alt + Print, which is not too long then

If we solve the first problem then this shouldn't be a problem anymore. Also changing default shortcuts can be annoying. I created a Task (T10574) for discussion about shortcuts feel free to comment there.

• Perhaps make the QComboBox a little bit wider for example from 240 to 250 [...]
  
  I think that looks quite good and would work. Opinions on this are appreciated!
  
  To the point with the amount of code for the little change, I was originally the same opinion, but I have thought about it a little:
  • The addition of Code in SpectacleConfig.cpp is not directly related to this addition, it was just missing (and should be added anyway)

If it's not related please submit another patch for that. In general I agree that a shortcut might be needed for "window under cursor" because "active window" isn't available on Wayland. But I don't know the reason why there never was a shortcut for that. It might be that it doesn't work reliably so wee would need to test that first. Also related T8033.

• The biggest addition has been the model. But this model has been there before (indirectly: used over insertItem()), it was just not in its own class. It already had 15 lines of code. Theoretically, it would be possible to use one of the existing models and do it directly KsWidget.cpp. But obviously we would basically need the same code as in the constructor of the custom model (around 30 lines) to get the shortcuts and do error handling. So personally I find it a lot cleaner and more easy to read in a seperate class (even though it's slightly more code because of the subclassing)
• The other bigger addition is the custom delegate: Basically it's the same, the actual code is in the paint() method ... the rest is just because of subclassing (which also means if we want to do other changes to that QComboBox, we will just need to change a very few lines of code now). In qml we don't need to subclass, so the code would be there much less for that part ... and I think at some point we will port Spectacle to qml?

I don't think the model is needed right now. The items already have the Spectacle::CaptureMode has Qt::UserRole data. You could then query the shortcut inside the paint method of the delegate. I think this would also have the benefit that it would display the correct shortcut if the user changes it while Spectacle is running.

So looking at it, most of the code addition comes through subclassing. But I think, and I might be biased because I've written the code, the subclassing part is very easy to read and it followed the model-view-delegate approach and is therefore quite clean. It actually helps keeping KSWidget.cpp clean, which is a lot more difficult to read.
What I would do though is make a new folder called something like "CustomComboBox" and put the new classes inside there. This way everyone should know directly that code in there is just for the combo box and the people, who start developing for spectacle won't get confused through the amount of files.
I would even suggest to make a folder "CustomComponents" and put "SmartSpinBox" in there as well.

Let me know what you think!

In D23362#517489, @Leon0402 wrote:

An idea to avoid calling layoutBottomHelpText would be to store the current screen rect as a member and only relayout if the center of the selection is outside the screen.

Yeah thought about that as well. But I suppose the screen rect is not really an attribute of that class from an OOP view. I think the actual problem is more that positioning logic has been mixed up with the logic for layouting.

QRect activeScreenGeo = QGuiApplication::screenAt(mSelection.center().toPoint())->geometry();
mBottomHelpContentPos.setX((activeScreenGeo.width() - contentWidth) / 2 + activeScreenGeo.x());
mBottomHelpContentPos.setY(height() - contentHeight - 8);

these lines are the only ones, which should be called through the update method. That's what I meant in my prior post that the structure of the methods is not good currently.

I noticed one small remaining issue on Wayland. If Spectacle is on my right screen and I start the selection no mid help text is displayed at all.

Works great now! An idea to avoid calling layoutBottomHelpText would be to store the current screen rect as a member and only relayout if the center of the selection is outside the screen.

In D23362#517409, @Leon0402 wrote:

Btw. another question:

Currently spectacle remembers the position of the rectangle from the last screenshot you made with that option. While that's undoubtedly a quite useful feature on small screens, I wonder if that's so good on a setup like you have. Because you might made a screenshot on your right screen the last time (something small in some corner) and now you want to make a screenshot on you left screen and you might get confused because the mid help text is not shown and you can't see your selection from the last time?
Not really sure if that's a problem, I just wondered if it would be more user friendly to only restore the last rectangle if it's one the same screen, where you open spectacle?

I think it's not a problem. The default is that spectacle only remembers the old selection until it is closed. Also I would be seeing the relatively big bottom help text on one screen. And I don't really find the old rectangle I can simply start drawing a new one by clicking and dragging.

The mid help text changes Screens correctly if I cancel my selection with right click. It will appear on the screen where the rectangle was.

Works really well now. I tested multipel edges corner, too (including whole screen selection). Code is also good from my side since I never really looked into it before.
What does VDG/@ngraham think about the new look when near a corner?

Testing on X:

• Is the mid help text (shown at the beginning) displayed on the screen, where you opened spectacle? Please try opening spectacle on different screens

No it's always on the left screen. The reason is probably we call drawMidHelpText if `mSelection.size().isEmpty() .

• Is the bottom help text displayed in the beginning on the screen, where you opened spectacle Please try opening spectacle on different screens

I don't understand. The bottom help text is only shown when I already created a selection, isn't it.

• Is the bottom help text displayed on the screen, where the centre of the rectangle is, you have created? Please try creating rectangles on different screens and also rectangles covering both screens

No. layoutBottomHelpText is only called once in the constructor.

In D23210#516766, @aprcela wrote:

Did some changes. Please check now.
Also: see the hint for doCopyToClipboard:

https://phabricator.kde.org/D23210#inline-131853

In D23210#516685, @davidre wrote:

Great! Now we also have to set the windowTitle and modification status like in KSMainWindow::imageSaved. Maybe instead of the showFeedback method we could do a imageCopiedAndSaved method inside KSMainWindow and connect that to the signal of the ExportManager. Like the imageSaved.
I think that would be cleaner. Do you agree? And after that one of us could do the same for just copying so that everything is consistent.

What exactly do you mean with 'for just copying' ? Add a signal/slot for Copying to clipboard, besides the doCopyToClipboard ?

In D23322#516683, @Leon0402 wrote:

This is how it would look like

or like this

Personal opinion:

• Not really better, but also not worse than the prior design
• Would require major code changes. Currently there is only one offset for each handle (we would need an offset property for every handle then), currently spectacle just looks if there is at least one screen edge in it's way ... for the change we would need to find out, we would need to check very screen edge separately and handle "corner situations" (where it's too close to two edges) as the offset for the corner handle should then only be applied once and not twice -> Possibly even more (design?) issues when the rectangle is small and the handles become free-floating
  
  It's probably not worth it and brings more disadvantages than advantages.

In D23322#516673, @davidre wrote:

This also removes the ability to resize the rectangle so that it can be moved when it's really small. I think we should keep that feature and only disable it at problematic sizes.

In theory this should be automatically resolved as the handles become free-floating if the size is too small. So they already have an offset of say 40px, which would be decreased by radius/2 ... so it's still about 35px outside of the rectangle and moving the rectangle should be possible without problems (Disabling the feature then might be still a good idea, as the space between the handles should be consistent). Or did I misunderstood you?
This means also that you cannot resize the rectangle on the edges atttached to the screen edges, if the rectangle is very small. But I cannot imagine anyone having a small rectangle in the screen corner/ at the screen edge and then wanting to make the rectangle even smaller from that side.

Another idea would be to only move them away from the edge but not change the height:

Great! Now we also have to set the windowTitle and modification status like in KSMainWindow::imageSaved. Maybe instead of the showFeedback method we could do a imageCopiedAndSaved method inside KSMainWindow and connect that to the signal of the ExportManager. Like the imageSaved.
I think that would be cleaner. Do you agree? And after that one of us could do the same for just copying so that everything is consistent.

In D23322#516683, @Leon0402 wrote:

This is how it would look like

Personal opinion:

• Not really better, but also not worse than the prior design
• Would require major code changes. Currently there is only one offset for each handle (we would need an offset property for every handle then), currently spectacle just looks if there is at least one screen edge in it's way ... for the change we would need to find out, we would need to check very screen edge separately and handle "corner situations" (where it's too close to two edges) as the offset for the corner handle should then only be applied once and not twice -> Possibly even more (design?) issues when the rectangle is small and the handles become free-floating
  
  It's probably not worth it and brings more disadvantages than advantages.

In D23322#516673, @davidre wrote:

This also removes the ability to resize the rectangle so that it can be moved when it's really small. I think we should keep that feature and only disable it at problematic sizes.

In theory this should be automatically resolved as the handles become free-floating if the size is too small. So they already have an offset of say 40px, which would be decreased by radius/2 ... so it's still about 35px outside of the rectangle and moving the rectangle should be possible without problems (Disabling the feature then might be still a good idea, as the space between the handles should be consistent). Or did I misunderstood you?
This means also that you cannot resize the rectangle on the edges atttached to the screen edges, if the rectangle is very small. But I cannot imagine anyone having a small rectangle in the screen corner/ at the screen edge and then wanting to make the rectangle even smaller from that side.

This also removes the ability to resize the rectangle so that it can be moved when it's really small. I think we should keep that feature and only disable it at problematic sizes.

Much better. Would it be possible to only move the markers on the edge which is at the border or would that look weird?

Or we create an ExportManager::doSaveAndCopy method which emits a new signal which then we connect to a new KSMainWindow::showSavedAndCopiedFeedback.

In D23210#516473, @aprcela wrote:

Update it to not use enum. Don't worry, it wasn't useless. I learned more :)

With this approach, we have one small problem. Now it tries to send both notifications. First the one that the image has been autosaved to location x, then the one that it has been copied to clipboard. This leads to not showing the first one at all, and the second notification gets drawn with a lag.
See comment at L275 in SpectacleCore.cpp

One solution, the only one currently that I can come up with, is to make ExportManager::doAutoSave which would emit imageAutoSaved and that one then calls KSMainWindow::imageAutoSaved which does only L478 and L479 (all three I mentioned, have to be created).
https://cgit.kde.org/spectacle.git/tree/src/Gui/KSMainWindow.cpp#n478

Do you have any idea of how to solve this double notification problem more simple?

First I would drop the notification and only show an inline message. For the problem that multiple inline messages are displayed after another: First let's simplifiy the logic here:
Instead of two two level ifs

if( copyToClipboard && autosave) {
    ...
} else if (copyToclipboard) {
    ...
} else if (autosave) {
}

For the feedback we could probably disconnect the mainwindow from the signal and then after sucessful save connect it back. Something like

disconnect(lExportManager, &ExportManager::imageSaved, mMainWindow, ....);
connect(lExportManager, &ExportManager::imageSaved, [](const QUrl& url) {
      mMainWindow->showInlineMessage(...);
      connect(lExportManager, &ExportManager::imageSaved, mMainWindow, ....);
});

Doesn't work with multiple screens:

In D23210#516297, @aprcela wrote:

In D23210#516294, @ngraham wrote:

Works great.

However, now that I see the three radio buttons, I realize that it might be nice to be able to auto-save as well as copy to clipboard, which seems to be what https://bugs.kde.org/show_bug.cgi?id=390415 is asking for. I wouldn't use it, but I guess the reporter would.

So instead of three radio buttons ("do nothing", "copy to clipboard", "auto save"), maybe we could actually simplify the UI to two checkboxes ("copy to clipboard", "auto save"), with both being unchecked implying "do nothing".

Thoughts?

Ok, I'll go with that one. Two checkboxes instead of three radiobuttons sounds good :)

Other option would be:

Give me a bit, atm fighting with git worktrees here :D

@davidre Can we still use the enums if we'd go with checkboxes only (instead of Radiobuttons)?

In D23162#515913, @aprcela wrote:

All done. I hope the names a re better now. Any recommendation for kde-dev best-practices?

Sorry for being annoying but I had a last look :)

Almost good to go now :)

In D23162#515885, @aprcela wrote:

In D23162#515855, @davidre wrote:

Last nitpicks:

• Since with your other patch this setting will control what happens after a Screenshot is taken and does not control what to copy to the clipboard, could you rename some variables accordingly?

is this renaming ok:
CopyImageToClipboardSetting -> AfterTakingScreenshotAction (everything, including enum)

enum CopyImageToClipboardSetting : int { DoNotChangeClipboard = 0, CopyImageToClipboard }
to:
enum AfterTakingScreenshotAction : int { NoClipboardChange = 0, CopyImageToClipboard }

nothingToCopy -> doNothing

CopyToClipboardGroup -> mAfterTakingScreenshotGroup

Yes I was thinking of something like that! NoClipboardChange should also probably be something like doNothing like the button.

• Write to GeneralConfig instead of GuiConfig. I plan to move some settings around so the place where they are configured corresponds to the their group.

As far as I can see, nothing of the stuff I changed and added gets written to GuiConfig. Can you link to something?
NVM, found it :)

Last nitpicks:

• Since with your other patch this setting will control what happens after a Screenshot is taken and does not control what to copy to the clipboard, could you rename some variables accordingly?
• Write to GeneralConfig instead of GuiConfig. I plan to move some settings around so the place where they are configured corresponds to the their group.

Landing this would make D23162 harder and the architecture while here simpler worse for that case. I will do an alternative patch after it is landed

Remove qDebug()

I would still like to land this even if we lose the image inside Klipper. It doesn't appear there everytime anyway and pasting still works as mentioned earlier.

Yes something like that. Thinking about it it could also be added to the Shortcuts page because it defines what happens when a Shortcut is pressed?

For the enum. You would define it inside SpectacleConfig and then save the respective value instead of a config entry for each option.

In general I'm fine with the approach taken here if we would just add this one setting. However we want to add at least one more button to this group. I think using an enum here and having only a single config entry would be better. Compare the printkeyactionrunning group.

In T11418#195847, @ngraham wrote:

Instead, could we have the DBus mode invocations read the current settings from Spectacle itself? The user can already configure whether to include the cursor via the main UI; it seems like it would be preferable to read this setting rather than adding a second one in the settings window to control the same thing.

In D23162#514293, @aprcela wrote:

In D23162#514292, @davidre wrote:

I don't think Copy file location to clipboard after saving belongs into the "After taking screenshot:" button group. It's confusing that it specifies two different points in time.

That one bugs me too.
To make more sense, Don't change the clipboard content and Copy image to clipboard should definitely go into the same button group.
Which means that Copy file location to clipboard after saving goes into a separate group.

There's one inconsistency tho, when a user activates both, we get the case 4) i mentioned up above. Which is very esoteric. See here:

In D23162#512390, @ngraham wrote:

1st put the screenshot in the clipboard, after it has been saved replace the clipboard content with the file location

This seems like a pretty esoteric use case. What would be the purpose? Can you envision why someone would want to do this. Also note that this isn't currently a feature that exists, so we're not debating taking it away from anyone, but rather proposing to add it in the first place. That makes the bar for adding it much higher. :)

One approach would be:
Two groups. First one called After taking screenshot: and containing Don't change the clipboard content and Copy image to clipboard.
Second group called After saving image: with a checkbox Copy file location to clipboard after saving and placed in Save, rather than General (as it used to be)

Take this patch also into consideration: https://phabricator.kde.org/D23210

Good idea.
With D23210 in mind however I would probably do

After taking  screenshot:  o Do Nothing
                           o Copy to clipboard
                           o Save Image

And have the other checkbox in the Save category as you said.

I don't think Copy file location to clipboard after saving belongs into the "After taking screenshot:" button group. It's confusing that it specifies two different points in time.

In D23162#512165, @ngraham wrote:

Thanks very much for the patch!

For patches that change the UI, it's customary to add a screenshot to the Test Plan section -- or even better, a video depicting it being used! Also the summary section is a good place to explain what your patch does, what problems it's solving, why you did it the way you did, etc.

In terms of behavior, maybe it would make sense to re-work the config UI so that each option has a radio button, and then only one can be active at once. Also, While this feature is on, I wonder if it makes sense to disable the Copy to Clipboard button on the main UI, since the screenshot will always be copied automatically.

+1 to radio buttons.
I would not disable the button since you could always want to copy the screenshot again after copying something else

Thanks! I also thought about adding such a functionality.

In D23080#510815, @ngraham wrote:

IMO the ideal state of affairs would be to somehow emulate the colors of the standard Qt tab widget:

Not too contrasty, but not too subtle either.

Should this set sectionDelegate: true and not expose this to the outside?

Can we revisit this? If you are notified about multiple mails there is no way to get from the notification to KMail currently since no buttons are shown.

Something to look out for https://phabricator.kde.org/D22684

restore me as the author

That should work

Arc mess up

Rework

• Use virtual desktops kcm list style and Kirigami actions
• Remove info button. The copyright info can be accessed by clicking on the item

In T10968#193645, @KonqiDragon wrote:

Maybe make a app pages with homepages style like in Konsole? Where everything will be written about this programs.

Boring:

Kool:

We have many apps and not all of them have the manpower to do this. The kde.org/applications are autogenerated. If all apps had pages with manually written content many of them would be quickly out of date again. See also the list in T10827.
Because of this the current approach is better. Autogenerated sites for all apps and for the apps that have their own website and the manpower to maintain them we link to it.

So the alternative approach would be something like this:

diff --git a/src/qmlcontrols/kcmcontrols/qml/ScrollView.qml b/src/qmlcontrols/kcmcontrols/qml/ScrollView.qml
index 8ef57a2..443f063 100644
--- a/src/qmlcontrols/kcmcontrols/qml/ScrollView.qml
+++ b/src/qmlcontrols/kcmcontrols/qml/ScrollView.qml
@@ -48,14 +48,28 @@ QtControls.ScrollView {
     onViewChanged: {
         view.parent = scroll;
         view.anchors.fill = view.parent;
+        setMargins();
     }

Sorry my bad, I misread the diff. I thought you added a new flag (as proposed above) and looked at exportGtkTheme but that flag is an existing one. And to my shame it doesn't even have a green background.

It seems the header with the new flag is missing from the diff.

@kossebau also wrote