- User Since
- Jun 19 2017, 12:29 PM (92 w, 11 h)
Sun, Mar 24
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.
Sat, Mar 16
Thanks for the patch. How is the gesture code going to get into KWidgetAddons now?
Fri, Mar 15
Updated the comment
Removed those four aAsConst again.
Tue, Mar 12
Albert, is this okay now?
Mon, Mar 11
- 'sides' --> 'side'
- updated old comment
Thu, Mar 7
Albert, is this okay for you now?
Ugly; didn't know about 'hidden detaches'.
Wed, Mar 6
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.
Tue, Mar 5
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':
Jan 12 2019
Guys, stop fighting. I'll make it optional in the next patch upload, all I need is a bit of time.
Jan 11 2019
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
Jan 9 2019
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.
Jan 8 2019
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?
Jan 7 2019
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. :-)
Jan 4 2019
Didn't we have this discussion millions of years ago?
Jan 3 2019
Jan 2 2019
Coding style: Opening curly braces go on the same line of the if statement.
Dec 30 2018
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.
Dec 23 2018
Thanks for testing!
Dec 22 2018
Dec 21 2018
Changed the GUI as suggested by Nathan.
Thanks! And apologies for not actually merging this much earlier.
Dec 18 2018
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.
Nov 28 2018
Nov 26 2018
Has anybody found some time yet to try the jump-to-page test?
Nov 17 2018
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 .
Oct 19 2018
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.
Oct 9 2018
- 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.
Oct 8 2018
Is there a good UI reason to force users to manually click "force rasterization", or is it just technical difficulty?
Oct 7 2018
I think so.
Oct 3 2018
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.
Oct 2 2018
Oct 1 2018
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.
Sep 25 2018
AFAIK for the manual you simply have to update doc/index.docbook.
Sep 24 2018
because gating these scaling options behind Force rasterization is not very user friendly
Sep 23 2018
I updated the diff. Apologies for the last version---it was really messed up.
Sep 21 2018
Doesn't this make Okular much less touch-friendly by default?
Sep 20 2018
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.
Sep 18 2018
Code is looking good to me. I tested it and couldn't find any problems.
Sep 12 2018
Sep 10 2018
Sep 7 2018
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.
Sep 6 2018
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.
Sep 5 2018
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.
Sep 4 2018
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.
Aug 30 2018
Aug 29 2018
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.
Aug 28 2018
Aug 27 2018
I see. So there is simply no option to disable the tooltips?
No, why would you want to disable them?
Aug 26 2018
Aug 24 2018
Sounds like a good idea to me.
Wow, I have never noticed that tiny 'welcome' window until now...
I see. So there is simply no option to disable the tooltips? And what does OSD mean anyway?