- User Since
- Jun 19 2017, 12:29 PM (100 w, 6 d)
Thu, May 23
My error. Apologies!
Wed, May 22
Tue, May 21
Fri, May 17
Is there an existing class for affien matrix operations?
Thu, May 16
Tue, May 14
I'm afraid we'll have similar objections to the endStyle, though, specifically “PDF only” — would that be okay?
Thu, May 9
Tue, May 7
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.
Mon, May 6
I think it should. But not in this patch.
Sun, May 5
At least squares and diamonds are incorrect, too.
I tried the circle line endings and they look a bit strange to me:
Sat, May 4
Thanks! Will commit on tuesday, if nowbody objects.
Thu, May 2
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?
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.