<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/115335/">https://git.reviewboard.kde.org/r/115335/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On January 27th, 2014, 9:42 p.m. UTC, <b>Albert Astals Cid</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; border-collapse: collapse; margin: 2px padding: 2px;">
<thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; font-size: 9pt; padding: 4px 8px; text-align: left;">
<a href="https://git.reviewboard.kde.org/r/115335/diff/1/?file=240733#file240733line4485" style="color: black; font-weight: bold; text-decoration: underline;">ui/pageview.cpp</a>
<span style="font-weight: normal;">
(Diff revision 1)
</span>
</th>
</tr>
</thead>
<tbody>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">4482</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "> d->middleMouseScrollTimer->start( 20 );</pre></td>
</tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Can you explain why the need for a timer?</pre>
</blockquote>
<p>On January 28th, 2014, 3:47 a.m. UTC, <b>Yichao Zhou</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">This is because, in scroll mode, user just moves their mouse a little bit and then does nothing. The screen will automatically scroll until user exits scroll mode (by another mouse click).
In order to let the screen scroll duratively, you will need a timer.</pre>
</blockquote>
<p>On February 3rd, 2014, 10:17 p.m. UTC, <b>Albert Astals Cid</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">And this is why the whole bug makes no sense. Okular already has a way to scroll that is using the left mouse button. And now you want to make the fact that middle mouse button also scrolls but in a different way. This makes no sense at all. I'm not going to continue reviewing this unless someone explains me why Okular should have two different ways of scrolling.</pre>
</blockquote>
<p>On February 4th, 2014, 3:40 a.m. UTC, <b>Yichao Zhou</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I do not quite understand this. How can I use the left mouse to do scroll? If you mean in "Broswer" mode and use the mouse to drag the page, then I can argue that
1. Using the middle mouse is more suitable when you want to scroll a large distance. The "drag" method is not very convenient when you want to scroll more than a screen: you need to move the mouse to the bottom of the screen, drag it to the top and then repeat this until you scroll to your target. _You need move your mouse a lot_. But for middle mouse, it is relatively simpler: You do a middle click. Then you move you mouse down a little bit (the scroll speed is determined by this displacement). Then the page starts to scroll. You wait until the page scrolls to the target position and then you do another click to stop the scroll. _You do not need to move your mouse a lot and you can achieve a higher scroll speed than using left mouse's method_.
2. For people migrated from adobe reader (or Windows), they maybe more happier using middle wheel to scroll according to their habit. (Although this is short, I think this is the main reason people request this feature on the KDE Bugtracking System).
3. Using middle mouse to scroll works in all mode including the "Broswer" mode.</pre>
</blockquote>
<p>On February 4th, 2014, 9:09 p.m. UTC, <b>Albert Astals Cid</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">1. Really? Have you even tried Okular? Because you do *not* need to drag your mouse to the top...
2. Do you know of any other app that uses that totally non standard way of scrolling?
3. So?</pre>
</blockquote>
<p>On February 5th, 2014, 3:51 a.m. UTC, <b>Yichao Zhou</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">1. I have said I do not quite understand what you mean by scroll using the left mouse button. I only know I can "drag the page", which really needs me to move my mouse up a lot if I want to scroll *a large distance down*. (Of course I can just set the page number or use the page up/down button, but that also requires me to move my mouse for viewer to toolbar, which may not be a small distance.) If I'm wrong, maybe you could described the desired behaviour of okular so I can see if I'm missing any feature.
2.
(a). Firefox, there is an option "Use autoscrolling", which enables you to use this way of scrolling.
(b). Libreoffice, I'm sure there is also a similar setting, even through middle click is important because it is a "paste" command by default, which is not a problem for Okular.
(c). Evince, the gnome's pdf reader also enable you using middle click to scroll *by default*. Although its behaviour is a bit different compared to this patch, it is at least compatible to people's habit.
What I list are the applications under Linux. Almost all the applications under Windows Operation System use this method to scroll, like Adobe reader, firefox, chrome, IE, Office and [[name any application using scroll heavily]]. Maybe it is a non standard way of scrolling under X, it is definitely the de facto scroll standard (except for using wheel) under Windows without doubt.
When I was new to okular (and Linux), the accidental resize of the document when you want to scroll is really really annoying! Although it is accpetable for me, since I'm used to use the wheel to scroll the page under Okular now. I just want to share a patch which may solve the similar problem that I have suffered!
In fact, in application such as Web Browser and Document Reader, what people mainly does is just scrolling page down! Maybe you do not really need it; maybe the code in pageview.h is in a little disorder now; but IMHO it totally is worth it!
3. So maybe it is more convenient for some people? People do not need to switch back for scroll if they want to stay, for example, at text selection mode? (I pretty like to stay at text selection mode since I can highlight the text that I'm reading.)</pre>
</blockquote>
<p>On February 5th, 2014, 8:58 p.m. UTC, <b>Albert Astals Cid</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">1. You said "You need to move the mouse to the bottom of the screen, drag it to the top and then repeat", that is simply not true, you can simply just keep moving up
2.
(a) A non standard option
(b) If you can't find it, how are you sure it is there
(c) Doesn't do what this patch does (it does what our left button does)
3) The fact that we should merge browse and text selection mode is a different issue, not an excuse for introducing a weird behaviour on the middle mouse move
Now, i could accept a patch in which middle mouse button did also move as left mouse one does in browse (i.e. the same thing that evince does) if enabling an option, but i don't see the need for a feature like the one you are presenting here.</pre>
</blockquote>
<p>On February 6th, 2014, 3:41 a.m. UTC, <b>Yichao Zhou</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">1. That's right. But you still need to move your mouse *a large distance*.
2.
(a). A non standard option? How do you define non-standard? Have any one organization make a standard to tell the world how middle click should behave? For firefox, it is not a plugin or something in "about:config", but is official supported and has a nice GUI option. It is ridiculous to add such an adjective: you can make verything you don't need to be "non-standard".
(b). I say "I'm sured" because I'm no longer using Libreoffice. But when I was using it (not very long ago), I always enabled that option. If you really need evidence such as a screenshot, I can install one for that.
(c). OK, that doesn't count. I shouldn't mention that. (In fact I hate that behaviour.) But I think (a) and (b) are persuasive enough.
3. Glad to here that. It will be better if there is a plan.
I don't know why you keep saying this behaviour is weired. Maybe people who have used Windows Operation System are all weird?
Don't see the need for such a feature? For conclusion: There are at least 5 users commented and requested for this "unwanted" feature in the bug report. In addition, I can prove that there are at least 2 large softwares under Linux and 5 large software under windows support this "weired" behaviour by default (under windows) or through an option (under linux). Also most users use "Adobe Reader" as their first PDF reader and it uses this "non-standard" behaviour by default. Please tell me how can I prove there is a need for this feature!
If you examine the bugzilla you will find I first commented several years ago. Recently, I spend time to implement this feature because YOU HAVE MENTIONED "Now if someone can come up with a patch that doesn't break the usage of the rest of Okular users please post it to reviewboard.kde.org" in the bugzilla. I cannot see how this patch breaks the usage of the rest of Okular users.
But for now it seems that I'm just wasting my time to update this patch and comment here.</pre>
</blockquote>
<p>On February 6th, 2014, 8:23 a.m. UTC, <b>Albert Astals Cid</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">1. Correct
2.
a) I meant non default
b) ok
3. Well, there is the need to do it, noone is working on i as far as i know
I keep saying is weird because there's very few applications (Sure firefox and libreoffice are big apps, but only 2) that implement it. Note i am not saying *people* is weird, i just find the feature weird. Moreover when it's at the app level, if it's at the operating system level as you seem to imply with Windows, then well, it's there and apps don't have to do anything about it, so it is consistent in that platform.
And yes, i do not see the need for this feature implemented at Okular level, if it was more common, maybe, but if we implement it, suddenly Okular will be the only KDE app that I know that does scrolling this way.
Note that you say that 5 people want this feature but what i read in the bugzilla is "if holding mouse mid button, perform scroll instead zoom", and that to me reads as "I want what evince does", not as "I want what this patch does" and that is why I mentioned I was open to seeing a patch.</pre>
</blockquote>
<p>On February 6th, 2014, 9:11 a.m. UTC, <b>Yichao Zhou</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">The original author may not state his problem clearly. For me, I can assure that there are at least three people out of six in the bugzilla think the patch should behave in this way:
1. János Pásztor (The original author of this patch)
2. Gregory M. Turner (Rewrite the patch)
3. Jonathan Doman (x11 workaround)
I think people who will request the feature is because they just migrate from Windows. Do I need to mail the rests to confirm their opinions?
To be clear, on windows, the feature is not implemented on operating system level. It is just a convention. For example, in notepad, which uses the native widget, does not support this feature.
For the problem only 2 applications under Linux implement it, I would say this is because they number of application needs scroll heavily is not so much: I do not need this feature in KWrite, GWenView, Konsole. But for Okular, what people do is almost just scrolling. That's why scrolling is important only for some limited applications. Notice that although chrome does not support it natively under linux, it is very easy to achieve this by install a extension.
For the concern that "Okular will be the only KDE app that I know that does scrolling this way", that still applies on the default "Zoom operation" or "Evince's way": I can say "Okular is the only KDE app that I know that does zooming this way". I think KDE does not have a uniform standard on the function of middle click. Konqueror just ignores the middle click when it cannot paste. It doesn't perform zoom also.
I'm confused why you can accept the evince's way: it is the only software does scrolling in that way. But refuse to accept the windows' style, which is much more popular.
How about extending the option to
1. Disable
2. Zoom
3. Evince' style
4. Windows' style</pre>
</blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">> I'm confused why you can accept the evince's way: it is the only software does scrolling in that way. But refuse to accept the windows' style, which is much more popular.
"Popular" is hard thing to measure, i've used lots of CAD/imaging software that use MMB press to pan like evince does while i've used no software that implements what you can "Windows style".
Ok, let's extend it to those 4 possibilities.</pre>
<br />
<p>- Albert</p>
<br />
<p>On February 4th, 2014, 4:39 a.m. UTC, Yichao Zhou wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Okular.</div>
<div>By Yichao Zhou.</div>
<p style="color: grey;"><i>Updated Feb. 4, 2014, 4:39 a.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="http://bugs.kde.org/show_bug.cgi?id=219121">219121</a>
</div>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
okular
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">According to the comments in https://bugs.kde.org/show_bug.cgi?id=219121, I implemented that feature with an option in accessibility pages.
This patch also fixes some problems in the original patch, and provides more features, including
* In scroll mode, you can press ctrl key to enter zoom mode
* Now you can use middle key to scroll in all mouse mode (broswer, zoom, selection, etc.)
* In scroll mode, now okular can load new page correctly</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>conf/dlgaccessibilitybase.ui <span style="color: grey">(9e76a75)</span></li>
<li>conf/okular.kcfg <span style="color: grey">(deabd07)</span></li>
<li>ui/pageview.h <span style="color: grey">(9c15af6)</span></li>
<li>ui/pageview.cpp <span style="color: grey">(65967bf)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/115335/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>