• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category User Interface
  • Assigned To No-one
  • Operating System Another
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by mcuelenaere - 2009-02-16
Last edited by jdgordon - 2010-10-14

FS#9918 - Touchscreen handling improvements

This patch improves touchscreen handling by adding these features:
* bigger scrolling bar which makes dragging it easier
* better handling of clicks/taps above the list itself (which results in exiting the current menu)
* fix ‘entering the first item when clicking on the empty space below a list which has less items than a full screen can handle’ * improve list scrolling in lists which has more items than a full screen can handle in the following way: when scrolling upwards with your finger, the lists scrolls downwards (which feels more natural) and vice versa

Closed by  jdgordon
2010-10-14 12:06
Reason for closing:  Out of Date
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

unless I'm missing something, the inclusion of kinetic scrolling (which mnight not actually be in svn yet, kugel is workng on it for android) means this isnt needed anymore?

Last time I used my D2, I thought that you simply held your finger in place to scroll up/down. Is your last point a description of dragging the scrollbar, or has the input mode where the screen is divided into buttons (rather than the absolute input mode) been changed at some point?

No, this patch only changes the behaviour on the absolute input mode.

About scrolling the scrollbar, I implemented this already some time ago, but as the scrollbar is rather small in SVN it’s a bit hard to use it to scroll through the list.

About my last point, you could compare it to the way how lists get scrolled on Android and/or iPhone/iPod Touch devices (see at ~0:10 as an example, my implementation is without the accelerated scrolling though).

I’m not sure making the scrollbar large is the best idea. It’s a device that comes with a stylus, so optimizing it for use with a finger doesn’t make sense to me. It’s penalizing those who actually bought it for what it came with, in favour of those who want to use it an alternative way. The larger scrollbar should perhaps be optional.

As for the scrolling, I understood what you meant regarding the directions, I just wanted to make sure it was only inverted in the absolute mode rather than the other input mode, that’s all.

I’ll probably commit the fixes (not the added features) and wait until someone with another touchscreen capable device (Cowon D2 probably) confirms this is also useful on those.

Regarding the larger scrollbar, this could indeed be an option in the settings menu; I’ll probably create an other patch entry for it when I get around that.

And regarding the directions being inverted in absolute mode, I don’t think this feels as being inverted (if you know how to use it); it feels much more natural scrolling like this than using normal scrolling (which actually feels inverted :) , at least to me that is).

I really like using the scrollbar to scroll though lists with this patch, it’s responsive and accurate and is exactly how I’d like to choose my music.

Even with the slightly wider scroll bar It’s still necessary to use the stylus or a thumbnail, in fact it’s probably about the right size for stylus-only use now. The bar is still pretty small, so I’m not sure an option is really necessary - just use the larger size for touchscreen targets (if anything it could be wider still, ideally skinned in some way).

I agree with Llorean about the ‘inverted’ scrolling though - it feels unintuitive and I really can’t use it. I find myself reaching for the scrollbar every time…

@Llorean, I thought your comment about “penalizing those who actually bought it for what it came with, in favour of those who want to use it an alternative way” was hilarious - remind me which project this is again?! ;-)

People don’t buy hardware going “I know it’s designed to work with a stylus, but I hope I get to use fingers on it some day.” People buy it knowing it has a stylus if they’ve researched it at all. Eating away their screen real-estate for people who’ve made a mistake is silly. Either make it an option, or let the people who actually did a little research into it use their stylus and save screen real-estate.

Penalizing them for actually knowing what they’re buying is silly.

Rockbox is about adding software flexibility, it’s not about taking *away* advantages of the hardware. A stylus lets you have more precise touching than a finger. If the hardware has that advantage, use it. Don’t make things large so that people can use their fingers when you know they have a stylus because it came with the hardware, that just penalizes the other people.

It should be an option, but it should never be unilaterally forced on people to lose screen space on something that did come with a stylus.

On touchscreen players that don’t have a stylus, on the other hand, and you’re intended to use a finger from the start, I’m all for somewhat larger inputs to account for the fact that you more or less must use a finger, and don’t think they should be penalized for people who always have a stylus around. They’re both sides of the same coin.

Design the default interface for the *hardware as packaged*, not for an *optional* way someone may choose to use it.

Did you actually read what I said before you embarked on that rant? I said the wider scrollbar was _ideal_ for stylus use, and that in fact the smaller scrollbar might not even be usable with a stylus. What on earth is your problem?

1) You don’t get to decide unilaterally what’s ideal for stylus use.

2) I’m not the person who mocked someone here with a comment of “remind me which project this is again?!”

I could as easily say “what’s your problem” but I instead explained why I feel it needs to be an option in cases where the hardware comes with a stylus. My “problem” is people who think it’s a valid response to just laugh off objections to changes with comments mocking another person, rather than attempting to actually discuss the validity of the changes.

Maybe next time, instead of making sarcastic comments in an attempt to negate the other person’s opinion, you could attempt to discuss the issue rather than trying to simply to mock it.

1) Who said I thought that? I commented that the wider bar is ideal, and that users might have trouble with the thinner one even with a stylus.

2) I didn’t mock anyone. I just thought your statement was quite funny when put in a different context. I didn’t realise it’d induce a chronic sense-of-humour failure. For that I apologise.

Either way I really don’t see how this is helping development of this patch.

As to 1) “It’s still necessary to use the stylus” says you’re deciding the stylus is necessary. If my opinion is valid, then it should be an option, and you didn’t need to say this. The only point in saying this, at the point you did, is to say you disagree that it should be an option, which would be you suggesting your opinion as to whether it is ideal should be taken unilaterally, since my proposition was to make it an option.

As to 2) I don’t see how you can possibly describe that statement as not being mocking. The context you created for it doesn’t even work since “Rockbox” as a project is about expanding the functionality of the players (what I suggested by having it as an option) rather than about saying “Okay, your player came with this object, but we’re going it ignore its presence” which is what mandating larger scrollbars than necessary would be.

As for development, if you hadn’t taken this sidetrack, all I was suggesting was that the larger scrollbar should be a separate issue/patch, and optional. Ideally it’d just be an integer option for width (or better yet, themeable and using the image’s width). This would allow anyone to use it at their preferred size.

Does anyone know how much of this was commited? is still being worked on?

Does anyone know how much of this was commited?

I think basically everything except kinematic scrolling went in.

is still being worked on?

Not me.

OK, so should this be closed? kinematic scrolling would be nice to add eventually if it isnt too hard to add

If there isn’t any opposition to kinematic scrolling (possibly with an option), I’m willing to look into that (not sure whether I should open a new patch for that?).

However, with RaaA on Android, perhaps there isn’t a need for this anymore as lists could be converted to use the native list-widget (I’m more inclined to work on stuff I’m personally going to use :) ).

I honestly dont ever see RaaaA using native widgets, and even so, I dont think just because of that we shouldnt bother with kinematic scrolling (especially if done in a way which lets people disable it if thye dont want it). But if you have no interest then no worries.

I do plan trying to hack Android’s native list widget in RaaA once it’s in a more advanced stage, whether it be included in SVN is something else though :)

I’m willing to rebase this patch and improve it a bit, I’ll see if I can find some free time.

This patch implements some kind of accelerated inverse-scrolling behaviour, it’s basically kinetic scrolling without the automatic scrolling.

The problem is I can’t force a screen redraw, which is needed for the automatic scrolling.
I’m currently doing this by (mis?)using the timeout API to “simulate” the scroll, but the screen only gets updated when the get_action() call times out or a button is pressed so you can’t see the actual scrolling..


Available keyboard shortcuts


Task Details

Task Editing