Comment 1 Andrew Flegg (reporter) 2007-12-15 16:54:21 UTC

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.

Comment 2 Roope Rainisto 2007-12-17 12:10:29 UTC

Yes, we are aware of this and actively working on this issue.

Comment 3 Eero Tamminen 2008-01-08 14:32:43 UTC

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
everywhere?  :-)

Comment 4 Andrew Flegg (reporter) 2008-01-08 15:20:06 UTC

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
report).

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
    application MediaBox.

(1) would free up more screen real estate in both full and non-full screen
modes.

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

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
the
     moment.

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

Comment 5 Andrew Flegg (reporter) 2008-01-27 11:32:12 UTC

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:

http://www.moblin.org/pipermail/dev/2008-January/001291.html

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

Comment 6 Quim Gil 2008-06-19 11:43:54 UTC

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.

Comment 7 Quim Gil 2008-07-03 10:58:06 UTC

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.  :)

Comment 8 Andrew Flegg (reporter) 2008-07-09 15:00:02 UTC

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.

Comment 9 Andre Klapper 2008-07-14 13:45:19 UTC

Let's close this when the code fixing this has been checked in. This may take a
while but is more correct IMO.

Comment 10 Roope Rainisto 2008-08-26 14:14:18 UTC

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.

Comment 11 Quim Gil 2008-10-27 08:12:25 UTC

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