- User Since
- Jun 19 2017, 12:29 PM (108 w, 15 h)
In bug 409638 it's probably a TabletEnterProximity event instead.
Sun, Jul 14
Agreed. I think the first step should be to write a unit test that triggers https://bugs.kde.org/show_bug.cgi?id=409638. That way we get a reproducible way to trigger the problem even for people without a stylus.
Fri, Jul 5
With the help of Tobias (thanks!) I wrote a unit test. You can find it at https://invent.kde.org/kde/okular/merge_requests/9 .
Mon, Jul 1
Tue, Jun 25
Albert, how much would a suitable pen cost you? I offer to give you one as donation if that would help you finish this patch.
Sun, Jun 23
I've been wondering whether it would be possible to write a unit test that sends out all the necessary events. That would allow to debug the problem without actually having the required hardware. Is that possible in principle?
I had the same problem yesterday and got around it by moving to https://invent.kde.org/kde/okular .
Albert, David, thanks for looking into this -- the problem seems to be a beyond my skill level. My hardware is a Lenovo Thinkpad Yoga, as in http://www.notebookreview.com/notebookreview/lenovo-thinkpad-yoga-12-review/ . I am not a stylus expert, said review calls it a "Wacom active pen stylus". I didn't have to do anything special to get it detected.
Sat, Jun 22
Thu, Jun 20
- Use localPos instead of screenPos
- Factor out intermediate Pixmap size computations
- Use QPainterPath for smoother paths
Path quality gets even better (slightly) if I replace the sequence of lines drawn by SmoothPathEngine with a QPainterPath. Do you prefer this change right here or in a separate patch on top?
Jun 15 2019
Jun 2 2019
Does https://phabricator.kde.org/D21543 help?
Jun 1 2019
May 23 2019
My error. Apologies!
May 22 2019
May 21 2019
May 17 2019
Is there an existing class for affien matrix operations?
May 16 2019
May 14 2019
I'm afraid we'll have similar objections to the endStyle, though, specifically “PDF only” — would that be okay?
May 9 2019
May 7 2019
I committed the patch, but without any icons at all. Even without them I think the patch is very helpful. The icons can now be added at ease in a separate patch.
May 6 2019
I think it should. But not in this patch.
May 5 2019
At least squares and diamonds are incorrect, too.
I tried the circle line endings and they look a bit strange to me:
May 4 2019
Thanks! Will commit on tuesday, if nowbody objects.
May 2 2019
I'd advocate to implement drawing the lines by code, i.e. QPainter::drawLine and friends. Then reuse the same code to draw icons.
Apr 11 2019
Thanks! I am happy with these comments (except maybe that people may read the "/ 60 fps" in line 3770 as a division).
Hi Kezi, I don't have a good answer to all that, I am just a bit distrustful regarding hard-coded constants like '6'. But I acknowledge that there are situations where they cannot be avoided.
How did you determine the value of the damping variable? You write
Apr 9 2019
Consider splitting the color change into a separate patch. That part seems to be uncontroversial.
I like the color part of this patch.
Apr 2 2019
Changed Mac OS X to macOS everywhere.
Apr 1 2019
It seems that I cannot write to this repository (I could only clone the anonymous git). Do I need extra rights? Can somebody push the patch for me?
Mar 26 2019
Is this okay now?
Mar 24 2019
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.
Mar 16 2019
Thanks for the patch. How is the gesture code going to get into KWidgetAddons now?
Mar 15 2019
Updated the comment
Removed those four aAsConst again.
Mar 12 2019
Albert, is this okay now?
Mar 11 2019
- 'sides' --> 'side'
- updated old comment
Mar 7 2019
Albert, is this okay for you now?
Ugly; didn't know about 'hidden detaches'.
Mar 6 2019
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.
Mar 5 2019
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?