- User Since
- Jun 19 2017, 12:29 PM (163 w, 3 d)
May 23 2020
May 15 2020
May 11 2020
The patch is now at https://invent.kde.org/kde/okular/-/merge_requests/163
Mar 5 2020
The patch is now at https://invent.kde.org/kde/okular/-/merge_requests/134.
Jan 15 2020
Jan 14 2020
Jan 11 2020
Dec 23 2019
Dec 4 2019
Nov 17 2019
Nov 15 2019
Nov 1 2019
Oct 29 2019
Oct 28 2019
@aacid , do you have the power to close this?
Oct 16 2019
Just to be sure: you are recommending to discard this diff, and to discard also https://invent.kde.org/kde/okular/merge_requests/47 ?
Oct 9 2019
Oct 8 2019
The tests do not pass. @aheinecke , do you have an idea? Could you abandon this revision and we continue discussion on gitlab?
Oct 4 2019
Let's see what the CI says:
Oct 2 2019
Any reason not to commit this now that https://phabricator.kde.org/D13171 is in?
Sep 30 2019
Sorry for being a pain, but your patch contains lots of whitespace changes again (in conf/dlgaccessibilitybase.ui). I agree that you probably do want them changed, but please do so in a separate patch.
Sep 20 2019
Sep 12 2019
The code looks promising, but I cannot test it because that kbusyindicatorwidget.h is so new it's not in my Debian yet. I am not sure we want to unconditionally depend on something so new.
Jul 16 2019
Could you put a qInfo() << *e in PageViewAnnotator::routeMouseEvent while reproducing bug 409638, so that we're sure what kind of events cause the trouble?
In bug 409638 it's probably a TabletEnterProximity event instead.
Jul 14 2019
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.
Jul 5 2019
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 .
Jul 1 2019
Jun 25 2019
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.
Jun 23 2019
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.
Jun 22 2019
Jun 20 2019
- 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?