Is this okay now?

I do use my stylus for drawing on slides in presentation mode. I am not particularly happy with the quality of that, but compressing tablet events doesn't seem to make it worse. So no objections from my side.

I tried this on my ThinkPad Yoga 12, which comes with a stylus to write on the screen with. I confirm that this patch noticeably improves the scrolling behavior when using the stylus for scrolling.

Thanks for the patch. How is the gesture code going to get into KWidgetAddons now?

Updated the comment

Removed those four aAsConst again.

Albert, is this okay now?

• 'sides' --> 'side'
• updated old comment

Albert, is this okay for you now?

Ugly; didn't know about 'hidden detaches'.

UI reworded following Nate's suggestions

• Do not use auto in range-based for
• Use qDeleteAll where appropriate

What is the behavior of the mouse buttons? In other words can the left mouse button make it go forward without being anywhere on the screen, and the right button make if go backwards.

That's the current behavior, ...

That's the current behavior, only with different UI text, right? That's fine with me. I will provide an updated patch within the next few days.

If I understand Albert correctly he wants to have the current behavior as an option. Your proposal does not offer that, does it?

Fine with me, too. If somebody is in favour of auto, please say so now. Otherwise I will remove the autos from the patch.

Not sure I fully understand your proposal. What happens if I uncheck the first option, check the second one, and then tap on the left half of the screen?

You may want to read up on range-based for; it is very helpful. In such a for-loop, auto always means "the type of a container entry".

Make the new touch screen behavior optional. There are three choices now in 'preferences->presentation':

Guys, stop fighting. I'll make it optional in the next patch upload, all I need is a bit of time.

New patch version:

• You can go back by touching on the left half of a touchscreen, touching the right half will go forward
• Mouse behavior is unchanged---left-clicking anywhere on the screen will go forward.

It's interesting that swiping down from the top with a single finger brings out the menu' so there does seem to be the potential of single finger swiping.

I think that swiping is a separate issue. One-finger swipes should actually be easy to implement as the difficult part already exists in the Gwenview patch mentioned above. And we probably all agree that one-finger swipes are better than three-finger ones.

I'd also prefer to leave the current behaviour of a left-click as it is

Some of these gesture recognizers would be very helpful in other KDE programs as well (Okular is what I have in mind). Can they be moved to some central place where both Gwenview and Okular can use them?

There's a GitHub project at https://github.com/giddie/poppler-cairo-backend , but from how I read the related bug report, upstream integration is very unlikely.

Actually, the necessary gesture recognizer exists, as part of a GwenView patch: https://phabricator.kde.org/D13901 . If that code was accessible from Okular, moving to one-finger swipes would be trivial.

That's the standard Qt swipe gesture. Anything else would require writing your own gesture recognizer.

Changing pages by swiping on a touchscreen works already (Qt requires you to swipe with three(!) fingers, though). But if I were a piano player using Okular to show me the music sheets I'd rather not swipe for fear of smashing the entire screen off the piano.

How about we let the new behavior apply only to touch events, and leave the mouse handling as it is?

The quality of the Arthur backend really depends on what you use it for. For example, I personally mostly use Okular for scientific articles and presentations, and Arthur works almost perfectly for that. But for other types of documents, however, the situation may be different. Only Albert and his test suite know. :-)

Didn't we have this discussion millions of years ago?

Whitespace fixes

Coding style: Opening curly braces go on the same line of the if statement.

Where are we at with this? What are the blockers to landing it?

Rebased to current master, and connected the code to the new print scaling modes.

Thanks for testing!

The patch here does not depend on D7949 anymore. It should fit directly onto the current master. D7949 does indeed need rebasing, which I will do as soon as this patch here has its final form.

Changed the GUI as suggested by Nathan.

Thanks, fixed!

Thanks! And apologies for not actually merging this much earlier.

Yes and no. :-) I was ready to implement whatever you wish without any further arguments, but then I got sidetracked with other things. It is still in the back of my head, though. Let me see if I get around to implementing your GUI before the weekend.

Has anybody found some time yet to try the jump-to-page test?

This looks like a definite improvement. It is still not perfect -- see my description at https://bugs.kde.org/show_bug.cgi?id=400890#c3 .

This new version of the diff adds tooltips to the new combo boxes. When the boxes are enabled, the tooltips hint at what they are good for. When the boxes are disabled, the tooltips tell how to enable them.

This is accurate.

ScaleMode:

• None: Do not apply scaling at all
• FitToPage: Scale the page to be printed such that it fits the target area as good as possible, without changing the aspect ratio
• ShrinkToPage: Like FitToPage, but only scale down.

Is there a good UI reason to force users to manually click "force rasterization", or is it just technical difficulty?

I think so.

I now actually tested and it works very nicely. I'll approve the diff, because I don't have a strong opinion on the whitespace issue.

I can indeed get the UI to freeze by zooming in a lot and then enabling Auto Fit. The patch fixes this for me, but to be honest I don't understand the code well enough whether the diff fixes the problem in the most appropriate way.

Are you sure you rebased this on the current master? The diff still seems to contain D15204 , which has already been pushed.

AFAIK for the manual you simply have to update doc/index.docbook.

because gating these scaling options behind Force rasterization is not very user friendly

I updated the diff. Apologies for the last version---it was really messed up.

Doesn't this make Okular much less touch-friendly by default?

Sorry for the delay, I have been wanting to fix this for quite a while now. Now that you nudge me about it I'll promise to update the patch before the end of the weekend.

Code is looking good to me. I tested it and couldn't find any problems.

Okay, my difficulties in reproducing the described behavior are explained now: I had an old file okularpartrc in .kde/share/config/, and the Kdelibs4ConfigMigrator kept migrating from that old file every time is started Okular without an okularpartrc. With that old file removed everything works as intended.

It really does take the file tools.xml from my development installation (tested with strace). Indeed, I deliberately purged my distro's okular from my computer a while ago, to avoid confusions like this.

When is your new okularpartrc created exactly? Afaikt, it should not be created right on startup, but only when you modify some tool in the config dialog.

You are right about QPixmap. The updated diff now uses a QPixmap object directly.

I cannot reproduce Part 1 of your test plan. When I delete my okularpartrc and start Okular (with the patch), then the freshly created okularpartrc file contains all colors as RGB, not ARGB. This doesn't seem to have any negative consequences, however.

Would it a good idea to split those changes that deal with the color alpha channel into a separate patch? That would make reviewing easier, and lead to more legible git history.

The updates diff makes the tooltips appear in the modes "Browse", "Selection", "Text selection", "Trim selection". These are the ones where the cursor changes to a hand when hovering over a link.

I see. So there is simply no option to disable the tooltips?

No, why would you want to disable them?

Sounds like a good idea to me.

Wow, I have never noticed that tiny 'welcome' window until now...