> On Jan. 27, 2014, 9:42 p.m., Albert Astals Cid wrote: > > ui/pageview.cpp, line 4485 > > <https://git.reviewboard.kde.org/r/115335/diff/1/?file=240733#file240733line4485> > > > > Can you explain why the need for a timer? > > Yichao Zhou wrote: > 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. > > Albert Astals Cid wrote: > 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. > > Yichao Zhou wrote: > 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. > > Albert Astals Cid wrote: > 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? > > Yichao Zhou wrote: > 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.) > > Albert Astals Cid wrote: > 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. > > Yichao Zhou wrote: > 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. > > Albert Astals Cid wrote: > 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. > > Yichao Zhou wrote: > 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
> 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. - Albert ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115335/#review48417 ----------------------------------------------------------- On Feb. 4, 2014, 4:39 a.m., Yichao Zhou wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115335/ > ----------------------------------------------------------- > > (Updated Feb. 4, 2014, 4:39 a.m.) > > > Review request for Okular. > > > Bugs: 219121 > http://bugs.kde.org/show_bug.cgi?id=219121 > > > Repository: okular > > > Description > ------- > > 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 > > > Diffs > ----- > > conf/dlgaccessibilitybase.ui 9e76a75 > conf/okular.kcfg deabd07 > ui/pageview.h 9c15af6 > ui/pageview.cpp 65967bf > > Diff: https://git.reviewboard.kde.org/r/115335/diff/ > > > Testing > ------- > > > Thanks, > > Yichao Zhou > >
_______________________________________________ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
