D25628: FEATURE: 414688 Add support for alternative scrolling method (prototype)

Yegor Ivashchenko noreply at phabricator.kde.org
Sat Nov 30 19:21:10 GMT 2019


yegori added a comment.


  In D25628#569866 <https://phabricator.kde.org/D25628#569866>, @davidhurka wrote:
  
  > Hey Yegor, I like this idea.
  
  
  Hi @davidhurka, thank you
  
  > I’m not sure what you mean with adding visual controls.
  >  Currently, auto-scrolling has no menu entries. Do you think there should be menu entries?
  
  I think it would be nice to have play/pause sort of button on instruments panel for example, but it is not required. 
  After using my prototype for a while I can say that next thing I would like it to have is a sort to easily set the auto-scroll speed. 
  As of right now there is no any indication what current speed is, and I have to just blindly click several times Shift+Down and Shift+Up to find the right speed.
  So it'd be very handy to have some way to set desired speed (i.e. using QSlider widget or free text input field with numeric values and up and down buttons) and then just "start" auto-scroll (with "play" button I mentioned before or special key binding, but visual element would encourage users to try and appreciate the new feature)
  
  > Or do you want a switch between the current auto-scroll behaviour and the new one? I think that can go into the settings (Configure Okular...).
  
  Yes, this kind of switch between current and new scrolling behavior can go into (Configure Okular...), but I don't have strong opinion on this.
  
  > I think you are aware of {naw Continuous} view mode. Auto-scrolling currently requires {nav Continuous) to be useful. For your suggested auto-scroll behaviour it will be the same, right?
  
  Yes, I guess so.
  
  Here's the list of thing to keep in mind a long the way:
  
  1. Auto-scroll speed is now determined as pixels/ms. I think it would be better if speed was determined by pages/minute, as right now there is a third factor which affect the actual time you have to read a page, which is view port height. If I set scale factor to fit page and I have speed 10 pixels per second and my viewport is 200 pixels height I'll have 20 seconds to read a page. If a make viewport twice bigger it will take 40 seconds to scroll the page, which should be the case to my mind.
  
  **Note** Super cool extra feature would be to be able to set scroll speed based on words/minute, as distribution of text is not always equal along the page, and now, having constant scrolling speed, I usually have to compensate that by scrolling down with mouse wheel from time to time to make auto-scroll to catch up with where I'm reading.
  
  2. Currently auto scroll can be turned off by many different actions, such as  pressing buttons, clicking mouse anywhere in viewport and others. I think that other scrolling methods shouldn't stop auto-scroll, for example if the page is left blank I should be able to press "page down" without stopping auto-scroll. I think there should be couple of methods to pause/resume auto-scroll, such as pressing space button, clicking left mouse button (on another click scroll resumes, or scroll resumes as soon as button is released, not sure yet), couple of ways to stop auto-scroll (for example special key binding, button in instruments panel). Difference between pause and stop is that after pause there are event which resume scroll, after stop those events don't resume scroll. Apart from that auto-scroll shouldn't be interrupted by any other actions.

REPOSITORY
  R223 Okular

REVISION DETAIL
  https://phabricator.kde.org/D25628

To: yegori, #vdg, #okular
Cc: davidhurka, ndavis, okular-devel, johnzh, andisa, siddharthmanthan, maguirre, fbampaloukas, joaonetto, kezik, tfella, ngraham, darcyshen, aacid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/okular-devel/attachments/20191130/6fa812c3/attachment-0001.html>


More information about the Okular-devel mailing list