Patch is ready for review.

Move SpectacleCore on the stack to avoid crashes, small refactoring

In D29282#668027, @davidre wrote:

So on screen we have the non rectangular pixel perfect pixmap but we return a rectangular pixmap? Which size will that have?

Add --new-instance option, clean deletion of app

Wayland was not concerned since screenshot replies are handled through file Desrcriptors.

In D29487#668034, @davidre wrote:

I would like to keep the option. We currently just start a new `Qprocess with "spectacle" would that still work?

I guess on app start you would check if there is an instance on the bus already and then do the right thing?

• Fix KSImageWidget cursor when there is no selection
• Send out a selectionChanged event when selection is cleared

In D29408#668033, @davidre wrote:

Why do we introduce the distinction between delayed and immediate? Is there a difference between delayed with 0 seconds and immediate? Also every screenshot triggered by the gui arrives at spectacle core with delay <= 0 because ksmainwindow waits the delay for the taskmanager animation and animating the button.

Yes thats correct. That makes it possible to save multiple different selections from the same screenshot... Maybe I should make it more clear that only the selection is saved, or is that clear? However, when dragging the selection only the selected part is visible in the drag image.

Ah I see, the select button will change the pixmap what is saved/copied but not the displayed one?

There should be a 'Select' button on the right side of the window (see below). Once you click it you can start a selection. During the time of the first selection the button is disabled. Happy to get feedback for the button location, label or better position.

In D29596#668032, @davidre wrote:

I had a similar idea to have a setting that controls what happens on shortcut press and when gui is running because currently the ui does not work for this. What we have is

So I have to check this box and it is under the "When spectacle is running" section. But the image will be autosaved regardless whether the other checkbox is saved or not. I think the problem is no easy but I will try again to think of something.

I would like to keep the option. We currently just start a new `Qprocess with "spectacle" would that still work?

Why do we introduce the distinction between delayed and immediate? Is there a difference between delayed with 0 seconds and immediate? Also every screenshot triggered by the gui arrives at spectacle core with delay <= 0 because ksmainwindow waits the delay for the taskmanager animation and animating the button.

I had a similar idea to have a setting that controls what happens on shortcut press and when gui is running because currently the ui does not work for this. What we have is

Very cool! However I can't seem to figure out a way to select a selection.
How do you think does this relate to D22074? Maybe we can integrate both patches somehow?

So on screen we have the non rectangular pixel perfect pixmap but we return a rectangular pixmap? Which size will that have?

Let me know @davidre if I can ease your review ;)

This patch currently implies removing the option to have multipe instances of spectacle, and we have a setting to have this upon pressing the Print key.
So should I keep the multiple instance mode ? @davidre @ngraham
It is feasible.
Any time the commandline with the background option or with the setting "Open a new Spectacle window" is set I would start a new Gui instance.

Just a heads up you don't need to use the weird lvariable, theParam code style. See discussion in https://phabricator.kde.org/D21042

Store QApplication on the stack

I don't see why qApp is not deleted here
https://api.kde.org/frameworks-api/frameworks-apidocs/frameworks/kdbusaddons/html/kdbusservice_8cpp_source.html#l00099
Probably because it can be allocated on stack.

Spectacle must have its executable in its desktop entry Exec field.
To manage this, spectacle must use KDBusService::Unique instead of Multiple.
This requires some refactoring.

In D28395#653949, @ngraham wrote:

Nah, I think for these new ones, just putting it on the clipboard is fine. The point after all is just to quickly paste an image into like a chat window or something.

Move deleteLater out of if

Add a deleteLater

one super minor change

Schedule an update instead of repaint in QuickEditor::onScreenConfigurationReceived

Rename dpr and dprI to devicePixelRatio and devicePixelRatio to differenciate to dpr variable that is per-screen, fix stroke color around selection

Can you add some more explanation what the code does in the summary?

Bonus points for moving items so that they are in the right order before committing (I know that the spacer was not in the right place before )

Removed hints

I think those appeared accidentally when I was testing how it would look like if the label text was shown as a tooltip for the Compression Quality label, I'll remove those and test it.

Everyone agree?

Sound good👍.

Thank you! I didn't add the shortcuts in this commit. I just wanted to confirm/ask some things before implementing them.

This is now being done in https://phabricator.kde.org/D28395.

Great work! Do you think you could also add new entries to desktop/org.kde.spectacle.desktop.cmake so that these are actually exposed in the UI and usable? That would be fantastic, and sufficient to fix https://bugs.kde.org/show_bug.cgi?id=416106.

Added 5 dbus method corresponding to the five modes of taking a screenshot.
They copy the screenshot to clipboard without saving them to a file.

Hello, Sorry about the mess. I have accidentally created a new revision, but I wanted to update this. I can't seem to figure out how to revert this.

In D23366#653823, @alex wrote:

First of all this feature sounds great!

I am just a bit confused about how we define "tasks" now:
In your current implementation it looks like they should be executed after the file gets saved.

And after capture a new window appears with a bunch of options

This seems like an action gets executed after the screenshot is taken.

Nah, I think for these new ones, just putting it on the clipboard is fine. The point after all is just to quickly paste an image into like a chat window or something.

First of all this feature sounds great!

Okay, Should it also include the functionality to be able to save to file AND copy to clipboard for the same screenshot?

In D23366#653219, @ngraham wrote:

I love the idea. However is it likely that the user will always want to run the same task on every screenshot? It feels more like this should be a list of tasks, and the user should be able to choose which one to run, optionally marking one as an overridable default task.

Thoughts?

I love the idea. However is it likely that the user will always want to run the same task on every screenshot? It feels more like this should be a list of tasks, and the user should be able to choose which one to run, optionally marking one as an overridable default task.

Merge and fix conflicts

In D23366#652581, @ngraham wrote:

Oh gosh, how did this get missed? Sorry about that.

Oh gosh, how did this get missed? Sorry about that.

I highly doubt it.
And thanks for reminding me. Will work on it in this week.

any chance of this being included in release 20.04?

In D22074#652046, @dporobic wrote:

Isn't it possible to the annotator? In ksnip it's hidden as long as you have no screenshot, so ksnip on startup is basically a toolbar.

Isn't it possible to the annotator? In ksnip it's hidden as long as you have no screenshot, so ksnip on startup is basically a toolbar.

I know it's a bit ugly but maybe we can then dynamically construct/destroy the annotator on button press to combat this?

In D22074#650858, @davidre wrote:

The reason that the spectacle window is larger on start because the annotator cannot be smaller because of the annotation tools sidebar I think

The reason that the spectacle window is larger on start because the annotator cannot be smaller because of the annotation tools sidebar I think

If you had plans to to fix the libkimageannotator build failure, you might want to just commit it yourself. I don't think the author is paying attention to the version on KDE infrastructure as I see it's developed on GitHub again at https://github.com/ksnip/kImageAnnotator.

• Fix