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

Right, so all five would need new functions. And yes, the rationale is to avoid changing existing function signatures which could break people and software already using them.

We have five modes for taking the screenshot.

In D28395#637705, @davidre wrote:

I don't think this is the right approach. You are just changing it for one method. Maybe we could make it configurable in settings,
Currently we have

After taking a screenshot: - Save
                                                  - Copy

That only applies when the gui is running Maybe we could find a solution to have it also apply when the ui is not up? Something like the above and a setting what should happen if you press shortcuts? What do you think @ngraham?

Thanks! Very nice patch. May it be the first of many. :)

Well, the name is Franz Baumgärtner , mail is: f.baumg at mailbox dot org . (If the name has to be ascii, please use ae as replacement for the ä.)

The two aren't linked, and I don't have the ability to see that page.

I've updated my information on https://identity.kde.org/index.php?r=people/view&uid=brainpower , but this seems to have not propagated to the phabricator profile? (yet?)

Nice patch.

This makes sense to me.

I decided to go with the suggested "just strip the subdirs".

In D28702#644877, @brainpower wrote:

@davidre:

Stripping the filename of subdirs would be fine with me.
I did try to be consistent, just in case something may not work otherwise.

Is autosaveFilename.section(QDir::separator(), -1); fine or would you like to have QUrl::fileName() used for stripping?

Stripping the filename of subdirs would be fine with me.
I did try to be consistent, just in case something may not work otherwise.

I wonder why we care about subdirs at all? If we do tempSave for drag and drop would it be sufficient to create the file in the tmp dir and strip the rest of autosaveFilename? This would save the need to create the subdirectories but I don't think it will make a big difference either way, but it's one thing less that could fail?

Sorry, I'll try to get to this soon.

Any updates on this?

remove leftover qdebug

I did this only for a single function to get feedback on whether this approach was acceptable.

I don't think this is the right approach. You are just changing it for one method. Maybe we could make it configurable in settings,
Currently we have

After taking a screenshot: - Save
                                                  - Copy

That only applies when the gui is running Maybe we could find a solution to have it also apply when the ui is not up? Something like the above and a setting what should happen if you press shortcuts? What do you think @ngraham?

Thanks for your patch.
However, I think you shouldn't change the existing method signature.

Hello, I've just submitted D28395 which adds the copy to clipboard capability for DBus, which this discussion mentions.
I had not seen this discussion earlier. Have I redone any already done work?

Can be closed.

It should not

Is this still relevant with D23316 committed now?

Looks and behaves nicely to me, but I am not a regex expert by any stretch of the imagination. @davidre, does this look okay to you?

Make xml nicer

20.04 is fine IMO.

Any advice if master only or also 20.04?

Will try. :-)

Nice catch!
Could you please add a test case for that?

I don't have a strong opinion either. I just thought that it could be of interest to capture only the app itself. Maybe at least for developers?
I think most users are primarly interested in the normal screenshot function and the other features are rather niche. (But it's hided in a popup and it's already there, so I see no particular reason to not have it)

In D27829#622613, @Leon0402 wrote:

Thanks a lot Nate!

I agree, the "window under cursor" mode makes no sense. Regarding the "aktive window" mode, I think it makes sense as it doesn't capture the system try?

Thanks a lot Nate!

• Fix button bug

This is really cool!

First it doesn't load. Because you hardcode the path to "src/MobileFrontend/main.qml" and don't even install the qml files it only works when spectacle is run from the source directory. I don't get the difference between mobile frontend and mobile backend. To me it looks like both are frontend and the backend class does only connect some signals.

• Change structure

Nice! First comments after quick look. Will try to find time this week for a more detailed review

@nicolasfella ping! Any chance of getting this in for 20.04?

Use qscopedpointer