maemo.org Bugzilla – Bug 2564
No consistency on scrolling/scrollbars in bundled OS2008 applications
Last modified: 2008-10-27 08:12:25 UTC
You need to
before you can comment on or make changes to this bug.
STEPS TO REPRODUCE THE PROBLEM:
* Compare scrolling the content area in:
o RSS reader
o Media Player
o Control Panel
o File Manager
o RSS applet
o Maps POI configuration dialogue box
* OS has a consistent, easy-to-use mechanism for scrolling content areas using
fingers or stylus.
* Dragging content area with finger or stylus causes the content area to
* Optionally with inertial/kinetic scrolling (though this is a different
enhancement request). This bug is focused on the UI breakage and confusing
interface caused by having at least 4 different scroll mechanisms in the
Each of the applications named above has a different scrolling method. The
following table summarises:
==== Scrollbar type ==== Drag to scroll Up/down buttons
Thin Normal Fat
RSS Reader | x x
Media Player | x
Browser | x x
Control Panel | x
File Manager | x
RSS applet | x x
The benefits of "drag to scroll" have been recognised in the browser and the
RSS reader, but should be standard throughout the device. The RSS applet's
up/down buttons should be scrapped in favour of this (no rearranging of the
desktop by dragging over its content area, but this is fine).
The consistent use of "drag to scroll" would also mean that precious screen
estate could be freed up by using a mobile phone-style scrollbar, showing only
the position (similar to that used in the RSS applet).
Third party applications like Canola, Maiku, UKMP and Kagu all use "drag to
scroll" very effectively. As do the browser (although it's a little tricky
finding a non-active piece of the content area, with the Gecko engine) and RSS
Reader in OS2008.
BTW, I forgot to say: comments of the form "CLOSED - WONTFIX: This is what the
UI specification says" will cause this bug to be re-opened.
If that's what the UI specification says, it's a bug in *THAT*, not the
implementation. The implementation of all these different scrolling mechanisms
seems, on the whole, to be fine. It's the fact there *are* all these different
scrolling mechanisms which is the bug:
1) Copying the desktop metaphors and then just making stuff bigger is not a
suitable approach to having a usable finger-friendly device.
2) Many different mechanisms for scrolling, with little to no consistency
within the *bundled* applications is not a suitable approach to having a
usable, consumer-friendly device.
Yes, we are aware of this and actively working on this issue.
Hm. The table seems to have a slight error, everything *else* except RSS applet
have up/down arrows in the scrollbar. The reason why it doesn't have arrows,
is that it's not a scrollbar, it's just a position indicator.
Another difference in the RSS applet is that its list focus/selection
wraps around at top&bottom whereas in all others it doesn't.
And when talking about lists, menus could also be thought as lists.
Too long Task Navigator menus have both scroll arrows at the bottom
(similarly to RSS applet), but normal Gtk menus have separate arrow
in both ends of the menu.
It would be good to have also a proposal how all these would be harmonized.
Surely you don't want thumbable scrollbars like the one in mediaplayer
By "arrows" I meant separate arrows for scrolling, rather than the usual
header/footer of scrollbars. This would be the two buttons from the right on
the toolbar of the RSS applet.
Your point about even more inconsistency when it comes to considering menus is
acknowledged, and gratefully received (it adds even more weight to the bug
My preference for resolving this, after careful consideration and comparison
with EPOC R5; desktop OSes and the variety of mechanisms in use in Maemo and
its applications would be the combination of:
1) A thin scrollbar similar to that used in the RSS home applet to indicate
position and size of viewport.
2) Drag to scroll, with an inertial element, as implemented in the third party
(1) would free up more screen real estate in both full and non-full screen
I would imagine this to be implemented at the Gtk container/widget level so
that all current scrollable widgets would implement the same behaviour (and the
"fat scrollbar" option removed). The OpenMoko project has implemented a
drag-to-scroll Gtk widget, designed for finger use. This deserves further
Drag-to-scroll may introduce problems with dragging to select multiple items.
Various options are possible here:
1) Have different portions of the list act differently (i.e. two columns
overlaid on the list: one which selects when dragged, one which scrolls).
2) Have a double-tap drag mean select, rather than scroll. This is the
expected behaviour in the Web browser and my own personal preference at
3) Have some other modifier or switch temporarily activate selection, rather
than scrolling. For example, holding down KP_Enter (the centre of the
d-pad) and then dragging could work well.
However, IMHO multiple selection is a much less primary use-case than
scrolling, and so scrolling should have the easiest and most consistent
Some information from the moblin mailing list on how application developers
there can take advantage of OpenMoko's scroll widget without having to hack
their glade files:
Even there they haven't got the option of getting it for free, so automatically
turning all GtkScrolledWindows into OpenMoko-style finger scrollers would give
maemo developers an edge, and ensure that ported applications are consistent
with the built-in software on ITOS (hopefully).
Moving to better location. I believe Diablo improves the situation a bit.
However is in Fremantle where all the UI is required to be fully consisten and
ready for finger use.
This will be fixed in Fremantle.
We can't discuss much details at this stage but if you trust the statement
above we can resolve this bug as Fixed - Target milestone Fremantle.
And make room for another bug in the ranking of most popular bugs. :)
Assigning bug, not sure I want to resolve it until a "fix is committed to the
tree and tested". If there are Fremantle builds internally which do fix this,
please feel free to resolve.
Until the plan item is developed, I'd say it should stay open - it could drop
off the plan and yet still be resolved, otherwise.
Let's close this when the code fixing this has been checked in. This may take a
while but is more correct IMO.
Yes, there will be major fixes to this issue in Fremantle. As with any bug that
is so general, the definition of a 100% fix is very hard. But it is certainly
one of the key improvement areas.
(In reply to comment #9)
> Let's close this when the code fixing this has been checked in. This may take a
> while but is more correct IMO.
After a second thought I disagree. This is a UI Spec bug and we are saying that
the UI Spec in Fremantle is clear about providing consistency on scrolling.
This alone fixes the bug with a Fremantle target milestone.
If then you find specific cases where this spec is infringed, please file bugs
against those cases.