Itemviews - ScrollPerItem, ScrollPerPixel

Matt Newell newellm at
Thu Jun 5 01:49:55 BST 2008

On Wednesday 04 June 2008 17:33:39 Rafael Fernández López wrote:
> Hi there,
> Those who are used to itemviews know that we have to set some flags to them
> for they working "properly". We have been discussing on IRC whether
> itemviews should have a ScrollPerItem or ScrollPerPixel scrolling mode.
> The default in Qt is ScrollPerItem, but somehow this looks like a bit 90's,
> and doesn't let the user easily "track the movements".
> This is specially critical, since the usage of itemviews have been extended
> to the maximum, as for example, what a combobox shows when being opened, is
> an item view.
> For example, I was asked to add smooth scrolling to the config dialog of
> plasma (backgrounds and themes), and had to do something like:
> combo->view()->setVerticalScrollMode(QAbstractItemView::ScrollPerPixel);
> what is pretty crazy all over the system.
> And there seems to be users that prefer ScrollPerItem to ScrollPerPixel.
> Given this situation, I propose the next (4.2, of course):
> 1) Create a new entry on KGlobalSettings. Something like:
> 	static QAbstractItemView::ScrollMode itemViewsScrollMode();
> 2) We have 3 different approaches at this point:
> 	2.a) Do let the developer read this value. Bad stuff: We only gain the
>              possibility of configuration, but we can't assure total
>              integration in the system, we would have to trust the
> developer, and he could miss this value, what could be very understandable.
> 	2.b) Create KAbstractItemView, KListView, KTreeView, KTableView. All of
> those will read on their constructor this value, and automatically set the
> value. We should always use K's classes on this case. We already have this
> rule. Problem: crazyness, probably impossible changes because of BIC.
> 	2.c) Add on kstyle.cpp, on the polish() method, the call to this method
>              reading the value of the setting. Problem: would only work
> with KStyles, not with QStyles.
> From my POV the best solution would be 2.c).
> We could add another check box, for example like "Smooth scrolling on
> itemviews" below the style selection. If the style is a QStyle the checkbox
> becomes disabled, while if the style is a KStyle it becomes enabled.
> Apart from special places, like for instance, Dolphin itemviews, after
> having a solution, we should remove those calls where we force one or the
> other.

Wouldn't 2c end up overriding code that depends on on setting or another?  I 
have treeview's that require ScrollPerPixel in order to keep the rows aligned 
with another custom widget that sits beside it.

Maybe the trolls could extend QStyle to provide the default(or some other 
mechanism that KDE can control), so that calls that happen before polish are 
not overridden.


More information about the kde-core-devel mailing list