- User Since
- Jun 19 2017, 12:29 PM (83 w, 19 h)
Sat, Jan 12
Guys, stop fighting. I'll make it optional in the next patch upload, all I need is a bit of time.
Fri, Jan 11
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
Wed, Jan 9
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.
Tue, Jan 8
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?
Mon, Jan 7
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. :-)
Fri, Jan 4
Didn't we have this discussion millions of years ago?
Thu, Jan 3
Wed, Jan 2
Coding style: Opening curly braces go on the same line of the if statement.
Sun, Dec 30
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?
Aug 23 2018
Aug 22 2018
Thanks for the patch.
Aug 14 2018
Fine with me. If you want I can post a separate QHash -> QMap cleanup patch. Either way, for me this patch can land in git.
Looking good! Concerning the preparatory commit 9ba8dd2cd7838c626af79a4edcd8b8437205cc02 , which copies the list of loaded generators from a QHash to a QMap: Why not use a QMap for them right away? Certainly the number of generators is low enough such that the efficiency differences between a QHash and a QMap become negligible?
I tested https://phabricator.kde.org/D14820 and it works nicely. Thanks for your effort! I also like the fact that the entries get sorted now.
Aug 13 2018
That's more than enough as an explanation, and too much to put it in the text. Can we simply mention the bug and diff numbers in the code?
Aug 12 2018
I think some extra comment lines explaining why this code is necessary would be helpful here.
Jul 20 2018
Also, would it make sense to have an (additional?) experimental option to enable the Arthur backend in general, i.e. for showing the content on screen (as a separate change), so people who really want to experiment can do so even more?
The patch should not influence the behavior of rasterized printing. The code used QPrinter with the poppler splash backend before, and it should still do that.
Implemented all suggestions. In particular, the new controls disappear now unless the experimental QPrinter option or 'force rasterization' is set. The code for this is not particularly elegant, and I'd be interested to hear from the Qt pros about how it should really be done.
Jul 18 2018
Jul 17 2018
Jul 10 2018
>Unlike for CUPS printing, Qt printing prints on the entire page and does not scale to the printable area yet. This is only because it is the easiest way. I > >plan to implement a few standard scaling methods in a subsequent patch, which will only be a few additional lines of code.
Applied Henrik's suggestions
Jul 2 2018
I just uploaded a new version of the diff that fixes all remaining issues. Also, I implemented type 3 support in the Arthur backend, and it is already in poppler 0.64. That was the last blocker that prevented me from being able to use the Arthur backend in my daily work.
Implemented all suggestions concerning i18n and capitalization.
Jun 25 2018
Jun 21 2018
May 31 2018
May 11 2018
I tried, but I still cannot reproduce it. I do see the spurious lines very very briefly when scrolling the hightlighted area into the viewport, but they are always removed.
May 10 2018
@simgunz , I can't. Remember that I could never reproduce the artifacts that Albert is seeing. Therefore I cannot test whether your idea fixes them.