Itemviews - ScrollPerItem, ScrollPerPixel

[Luciano Montanaro]

-----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-----