Itemviews - ScrollPerItem, ScrollPerPixel

[Robert Knight]

> I don't know. You are talking of "smooth scrolling" here, right?

No, that is something different.  The debate is about how much of the
display is shifted when you move the scrollbar up and down, not whether
there is any acceleration involved.  With the Qt default, moving the
scrollbar does nothing until you move far enough to reveal a whole item.
The display then "jumps" so that new item becomes visible.

With scroll-per-pixel the display scrolls by a certain proportionate
amount whenever the scrollbar is moved.  In either case, there is no
acceleration, the display is either scrolling or not scrolling. 

"Smooth scrolling" as found in Konqueror is where there is acceleration
involved so that the scrolling starts off slow, gets to full speed then
slows down again when you let go of the scrollbar/mousewheel.  

Regards,
Robert.

On Sat, 2008-06-07 at 10:56 +0200, Luciano Montanaro wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thursday 05 June 2008, Robert Knight wrote:
> > > And there seems to be users that prefer ScrollPerItem to ScrollPerPixel.
> >
> > Are there really enough of them to warrant going to the trouble of
> > making it configurable system-wide?
> > If not then just changing the Qt defaults would be preferable.
> >
> 
> I don't know. You are talking of "smooth scrolling" here, right? If that's the 
> case, I can tell I've found it an extremely irritating feature since I first 
> spotted it in some text editor on the Amiga, quite a few years ago...
> 
> If the implementation is similar to the one in Konqueror(4.00.80), it looks a 
> bit inconsistent too: 
> Paging up or down does not smooth scroll, as well as scrolling up or down 
> withe the arrow keys. 
> Using the mouse wheel, the page slowly scrolls to place... the scollbar snaps 
> to the new positin immediately, however (no smooth animation there).
> 
> Anyway, for reference, Firefox 3 does have a "smooth scroll" checkbox; so it 
> looks like the Firefox developers find that at least some of their users 
> could like to choose to turn the feature off.
> 
> Whatever you choose, I'd say the animation should be way faster than it is 
> today.
> 
> Luciano
> 
> > Regards,
> > Robert.
> >
> > 2008/6/5 Peter Penz <peter.penz at gmx.at>:
> > > Hi Rafael,
> > >
> > >> Hi Peter and all,
> > >>
> > >> > When porting Dolphin to KDE 4.0 I was told that Trolltech hopes that
> > >> > no KListView, KTreeView, ... classes are required anymore because of
> > >> > having QAbstractItemModel and QAbstractItemDelegate.
> > >>
> > >> Well, I don't see the point of this statement :)
> > >>
> > >> We want to add two different kind of scrolling to the user
> > >> configuration. That  belongs to the view, nor the model or the delegate.
> > >> So, we should apply that  configuration to the view.
> > >
> > > I fully agree :-) What I wanted to say is (sorry for being unclear): For
> > > KDE 4.0 the introduction of KListView, KTreeView, ... classes has been
> > > dropped on purpose. If I remember the discussion correctly the
> > > introduction of K... counterparts in KDE 3 also resulted in some problems
> > > and it has been said that we should not introduce a K... class when the
> > > Q... class already provides all the functionality. However I think this
> > > decision was wrong in the case of item views.
> > >
> > > Regards,
> > > Peter
> > >
> > >> Regards,
> > >> Rafael Fernández López.
> 
> 
> 
> - -- 
> Luciano Montanaro //
>                 \X/ mikelima at cirulla.net
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> 
> iD8DBQFISk1AaeOY6B53J4URAvpsAJ0QGX/YfutQI7FUIuMu16q1kpaWAgCfRT7B
> CH+J9r8gaEzuZ/z7QCWBJmQ=
> =PAAO
> -----END PGP SIGNATURE-----