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?

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.

Didn't know about D22074 but looks cool and useful. Had a quick look at the code and if I get it right it simply swaps out the whole KSWidget layout with the external KImageAnnotator widget. So that should make it easy to work together with my patch.

I guess once a selection has been done the annotation tool should work on this selection. This is not a problem because I changed the ExportManager to only return the selection. However, we probably need to consider cases where the selection is very small and the annotator has not enough space to be useful... Apart from making both patches compile together I don't seen any problems.

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

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.

That's a nice feature.

This is going to conflict with D29282 :/

Do you see fundamental problems combining both patches? e.g. in the KSImageWidget the mScreenRegion could simply be a single rectangle of the size of the screenshot pixmap?

Or some other option to reuse the drawing and user interaction from QuickEditor?

In D29550#669814, @czeidler wrote:

Do you see fundamental problems combining both patches? e.g. in the KSImageWidget the mScreenRegion could simply be a single rectangle of the size of the screenshot pixmap?

Fundamentally no, the other patch essentially rewrites QuickEditor::paintEvent to support Wayland per-screen scaling/dpr.
The full screen rectangular selection and the in-KSImageWidget would need to have separate paint functions essentially.

But since this patch moves files around this alone introduce a lot of rework in my branch should my patch land after yours.

I had another thought on it and think having all the functionality for both cases in one class is probably a bit too big and both use cases are actually too different. The common part that can be shared between both cases is the selectable rectangle + the magnifier. I think all other functionality / logic should go into QuickEditor and KSImageWidget respectively. I am wondering if that is an option, i.e. refactor a selection primitive to select a rectangular area (possibly implemented as QGraphicsObject). I assume that's what you need as well, right? i.e. you want a rectangular selection rather than a region? We could make this new selection class customizable with an isValidSelection hook / lambda so that in your case you can reject selections that are invalid. (correct me if you need something different, I am still not 100% sure if I understood your problem right, if you have a screenshot of a distorted / problematic screen that would be great!)