Bug 198501

It is possible to use TAB to scroll items... is it enough?

what if you do not have a keyboard? Are there any other lists without scrollbar? If not, why should this be an exception?

SVN commit 998548 by jacopods:

Fix scrolling of results using the mouse by adding two page buttons to the view 
As a bonus, ws cleanup and make sure the configWidget disappears when items are re-used
BUG: 198501
This will be backported to 4.3 


 M  +1 -0      CMakeLists.txt  
 M  +22 -28    interfaces/default/interface.cpp  
 M  +6 -1      interfaces/default/resultitem.cpp  
 M  +9 -8      interfaces/default/resultscene.cpp  
 A             interfaces/default/resultsview.cpp   [License: GPL (v2+)]
 A             interfaces/default/resultsview.h   [License: GPL (v2+)]


WebSVN link: http://websvn.kde.org/?view=rev&revision=998548

SVN commit 998549 by jacopods:

backport page buttons + cleanup (r998548)  
CCBUG: 198501



 M  +1 -0      CMakeLists.txt  
 M  +23 -29    interfaces/default/interface.cpp  
 M  +6 -1      interfaces/default/resultitem.cpp  
 M  +9 -8      interfaces/default/resultscene.cpp  
 A             interfaces/default/resultsview.cpp   [License: GPL (v2+)]
 A             interfaces/default/resultsview.h   [License: GPL (v2+)]


WebSVN link: http://websvn.kde.org/?view=rev&revision=998549

We did not implement a scrollbar for design reasons; 
for a screenshot of the actual implementation please check:

http://reviewboard.kde.org/r/948/s/135/

Thanks

The arrow is hardly visible. This is still an usability issue. Should I open a new report for that?

That is mainly a theme issue (works perfectly fine with the oxygen theme). In fact please open a new report so that we can CC the oxygen people just for this issue.
Thanks

Sorry, but oxygen is not working well. See attached screenshot, the arrow is nearly invisible.

Created attachment 35847 [details]
spot the arrow

it would help if the font you were using wasn't so horrible :/ in any case, we'll probably eventually also implement click-hold-drag scrolling.

(In reply to comment #8)
> Sorry, but oxygen is not working well. See attached screenshot, the arrow is
> nearly invisible.

btw the theme you are referring to is called "air" not "oxygen" (which is the old black default one).

(In reply to comment #10)
> it would help if the font you were using wasn't so horrible :/ in any case,
> we'll probably eventually also implement click-hold-drag scrolling.

What does the font have to do with the arrow's size being too small to be spotted easily? Or the "scroll action" being at a place the user is not used to?

The scrolling is not only about the ability to scroll (without a mousewheel or without keyboard) but also about showing that there is more. As you can see in the screenshot, there is no indication that there are more than those three entries, because the last one ends where the window ends.

And the font is Arial truetype with bytecode enabled and anti-alias disabled, it does not get sharper than that. Why it is used in italic I don't know, as I did not set that up, I guess it's default.

@Jacopo: Regarding the theme, it's true, I thought you meant the windeco, which does not make sense since this obviously depends on the plasma theme. But hey, air is only default in KDE 4.3.

> As you can see in
> the screenshot, there is no indication that there are more than those three
> entries, because the last one ends where the window ends.

Actually the results fade close to the edge, that should hint you that "there is more to scroll down there".. indeed it's hardly noticeable with the font you are using.

> @Jacopo: Regarding the theme, it's true, I thought you meant the windeco, which
> does not make sense since this obviously depends on the plasma theme. But hey,
> air is only default in KDE 4.3.

I know that air is the default; what I meant is that the fact that it is gray on gray it is a theme issue and not a krunner issue and it has to be addressed as such; I'll talk with the theme coordinator about that, but if you open another bug about that, it will be easier to track things as they evolve. 
Thanks

(In reply to comment #13)
> Actually the results fade close to the edge, that should hint you that "there
> is more to scroll down there".. indeed it's hardly noticeable with the font you
> are using.

As I mentioned, this is a high quality Sans Serif font, so that is no excuse. I also fail to see how fading another would be different with another font.

The fading out IMHO is not suitable as a signal either because it is used in notification, menus etc. if the content of the shown item does not fit the window (you are right on that one) but none of those offer a scrolling in the fading direction. Neither do they indicate that there are more items, just that the shown item has more text. So the fading does not indicate "scroll to see more items". If there are more items, a scrollbar is used.

> I know that air is the default; what I meant is that the fact that it is gray
> on gray it is a theme issue and not a krunner issue and it has to be addressed
> as such; I'll talk with the theme coordinator about that, but if you open
> another bug about that, it will be easier to track things as they evolve. 

I hestitated because I do not think that it would fix the issue in the right place, i.e. scrollbars are the common signal and tool for scrolling and should be used to mediate "more items" in a list. Further the size is too smal, if the user does not hover it by accident.

Anyway, bug 202587 is about the visibility in hope that the other issues are  addressed as well.

> So the fading does not indicate "scroll to see more items". 

Granted, in fact that's why we also show arrows.

> Anyway, bug 202587 is about the visibility in hope that the other issues are 
> addressed as well.

Thanks