Removed unneeded parts from old diff

In D9342#301838, @rkflx wrote:

Oops, I think there was a misunderstanding. P250 was against the stable branch, not against your patch.

In D13249#301464, @rkflx wrote:

We might have to research what's the maximum allowed size, and add a check to Gwenview. (Would you like to work on that? Not really urgent, though.)

In D14485#300895, @rkflx wrote:

Thus, can we work on this later, given that it's not quite ready yet and it's for master anyway?

In D9342#301657, @rkflx wrote:

Okay, here's my patch (don't laugh, I know it looks fishy): P250

Added modifications from P250 by rkflx

In D13249#300894, @rkflx wrote:

• How to fix the issue in kdeclarative? Or report a bug and hope for the best?

In D13249#301085, @muhlenpfordt wrote:

I'll take a look at the imagedata setting. Setting one special mime type may help as first workaround.

In D13249#300894, @rkflx wrote:

Can anybody confirm? If this is really an issue, obviously it won't be acceptable to ship Gwenview in such a state for 18.08, since setting the Plasma wallpaper by dragging to the desktop is a feature often asked for.

This version does its own cursor handling inside the edit tools.
I first tried it by ignoring/accepting the mouse and key events and let AbstractImageView show the magnifying glass (see preview Diff 38774), but for crop tool it still doesn't work in all situations. Sometimes an event has to be accepted for one action but the same should be ignored to do something in AbstractImageView.

Looks good. I found no other usage of (Shift)+E, except in browse mode - but this tool/action is disabled there anyway.
It's also no KStandardAction, so we can set the shortcut without respecting any preexisting.

I'm not a reliable source for english wording... ;)
In german I would always expect a plural version, i.e. "Reduce Red Eyes" (Rote Augen reduzieren) - even if I edit one at a time.
But I think "Red Eye" as short version for "Red Eye Effect" is ok.
I've also found "Correct Red Eye(s)" or "Fix Red Eye(s)".

I tested a couple of situations in crop tool witch your first patch but never noticed the cross hair cursor until you pointed it out.

In D14324#297603, @muhlenpfordt wrote:

But I'm stuck with resetting the cursor since the mouseReleaseEvent seems to get lost for Ctrl+click - that's why the ClosedHandCursor still shows up.

Found the reason for this. :)
The previous mousePressEvent needs to be accepted somewhere (for zooming in AbstractImageView), otherwise the subsequent mouseReleaseEvent is not triggered.

Using Ctrl+Left-/Right-Click changes to the closed hand cursor - but that's what you noted before.
Anything else works good. :)

Works good and I can't spot any visual difference. :)

In D14324#297165, @rkflx wrote:

Ctrl zooms nicely too, but would it be too much to ask to show the correct cursor, i.e. the magnifying glass? Also, for Red Eye Reduction, the cursor seems to be stuck on ClosedHandCursor. Perhaps this is an issue of propagating the key press events?

I got this partly working by ignoring some more events in the right places and let AbstractImageView do the cursor work.
But I'm stuck with resetting the cursor since the mouseReleaseEvent seems to get lost for Ctrl+click - that's why the ClosedHandCursor still shows up.
I think this is a bit more complicated and maybe better go to a different patch.

Removed filtering Qt::ShiftModifier

Use valueChanged signal
Set explicit max value for spinbox too

In D14286#296557, @rkflx wrote:

Making Ctrl-right/left click and middle click work for tools too (where it makes sense) is not that easy, is it?

In D14284#296087, @steffenh wrote:

display the active image name, if you have more than one image in the view mode

Do you mean that in Compare mode the window title should change when clicking on another image? For me this is already the case without your patch.

Interesting, in KDE Neon 5.13 (Plasma 5.13.2, KDE Framework 5.47.0, Qt 5.11.0) yes it works without my patch. In my working Linux (OpenSuse Leap15.0, Plasma 5.12.5, KDE Framework 5.45.0, Qt 5.9.4) is it doesn't work without my patch.

In D14269#295718, @rkflx wrote:

Refactoring sneak peek (headed for master, will post a Diff once the bug fix landed), which still needs testing and a commit message: P243

In D14181#294835, @rkflx wrote:

That's how merging works: Every commit from stable will (and should) be present in master

First I landed to stable as usual:

$ git checkout my-branch
$ arc land --hold --onto Applications/18.08
$ git push -- origin ...:Applications/18.08

Then tried to merge into master and got something like this:

$ git checkout master
$ git merge -Xours origin/Applications/18.08
$ git log
commit 2a375e0165ae1d666c2e62f4c22b71b7c53574f7 (HEAD -> master)
Merge: 8cbc6377 e6026082
Author: Peter Mühlenpfordt <devel@ukn8.de>
Date:   Thu Jul 19 13:02:23 2018 +0200
    Merge remote-tracking branch 'origin/Applications/18.08'

Was that ok how I pushed this to master?
There are two different GIT_SILENT ... commits in Applications/18.08 and master, which I got both after using git merge -Xours origin/Applications/18.08.
Now I used git cherry-pick <commit> to get only this commit.
Do we have to use this from now on while 18.08 lives?

Increase readability of zoomIn/zoomOut functions

The new shortcut is just a suggestion. If you wish to use another or even any better solution to a possible conflict, I can surely update this patch.

Just found this wish for adding Ctrl+0 to KStandardAction::ActualSize.
https://bugs.kde.org/show_bug.cgi?id=305702

Zooming in/out in synchronized compare mode looks a bit strange sometimes. But this did not change by this patch.

Tested with the updated master and it works great now.
(Centering to cursor on Fill to be done.)

In D14093#293037, @rkflx wrote:

However for Fill there is a decision to be made where to pan to. For some cases (e.g. zooming out) this already works okay, but for zooming in from the minimum zoom level it does not:

Map cursor position to current image
Limit cursor centering to image view

In D14093#292918, @rkflx wrote:

• In Compare mode it does not work right for every document. Adding mapFromScene fixes it for me.

In D14094#292125, @rkflx wrote:

Well, in general silently breaking other apps is not nice. In this case there does not seem to be lots of active development, so perhaps just posting a Diff and tagging the contributors of the last few patches (Kai and Andreas) is better than opening a bug or asking others to solve the issue for us. (Let me know if I should help, IOW if I was asking too much from you ;)

Center 100% zoom to current cursor position

In D14103#292352, @rkflx wrote:

In D14103#292346, @muhlenpfordt wrote:

Sadly the centering to mouse position when zooming to 100% gets lost with our combination.

Interesting. Is this really working for you without the patches? For me, even middle-clicking with a KDE4-based Gwenview centers instead of respecting the mouse position.

Code looks good to me.
Sadly the centering to mouse position when zooming to 100% gets lost with our combination.
Should I add this to DocumentView::toggleZoomTo...()? It will work for both shortcut (maybe surprising for users?) and click.
Or add an argument to pass the mouse position only for click events?

In D14094#291579, @rkflx wrote:

Would it be too much to ask to solve this, e.g. by removing the conflicting standard shortcut?

Remove shortcut for "100%"

I think there are two reasons that make it necessary to move the toggling code to separate slots:

• DocumentView::setZoomToFit/Fill() is used from various locations where the on parameter is important
• The parameter checked of the triggered signal and the checked state of the zoom actions are unusable since they're always true when the triggered slot is called - this seems to be an effect of the QActionGroup in ZoomWidget linking all zoom buttons.

Move toggling code to separate slots

In D14094#291481, @rkflx wrote:

I should triage more bugs if this seems to result in quick fixes ;)

Removed SignalBlocker include

In D13795#289375, @rkflx wrote:

• This causes File → Open to not start in the current directory but in Gwenviews initial or last set path. In addition, due to adding StripTrailingSlash, D9886 caused the file dialog to select the last subfolder as a file instead of entering it. Both problems can be fixed by using QFileDialog::setDirectoryUrl() instead of QFileDialog::selectUrl().

Works perfectly now. No more issues found. :)

Thanks for diving that deep into this! Looks like a hard piece of work.
Ok with the commit message / comment? Better suggestions always welcome. ;)

Added comment for Save As dialog

I found some small issues:

• Pressing Ctrl outside and moving the mouse to Gwenview does not update the cursor (AbstractImageView::focusInEvent() is triggered but mControlKeyIsDown is false).
• Switching from Browse to View Mode with Ctrl+Return does not display the magnifying glass (not really important... ;) ).

Maybe these could be fixed by something like this?

bool newState = QGuiApplication::queryKeyboardModifiers() & Qt::ControlModifier;
if (newState != d->mControlKeyIsDown) {
    d->mControlKeyIsDown = newState;
    updateCursor();
}

The behaviour of QFileDialog::selectUrl() seems to have changed between Qt 5.9.1 and Qt 5.9.5.
On an older Kubuntu 17.10 system the initial path is set by QFileDialog::selectUrl() but not on Kubuntu 18.04.
The changed code also works with the older library version.

In D13754#284182, @rkflx wrote:

The only thing I'm not sure about is showErrorMessage(): Why did it work in KDE 4, but does not work anymore? Your new code is fine, but maybe we also have a problem in KF5, which obviously we should try to fix (or we might run into it again and again… – e.g. did you check GVPart::showJobError?).

Remove showErrorMessage() call