> Maybe scrolling itself could be sacrificed. What if we use the scroll > wheel like this: when you scroll down, actual scrolling down will > start, and will increase in speed if you keep turning the wheel. It > will only slow down, and eventually stop if you scroll up again. The > same goes for scrolling in the upward direction. Sort of like the > middle-click scroll behaviour in Windows, only without the clicking, > and using the scroll wheel instead. > > Middle-click can then continue to be used like it is used now. > > Remco
We should remember that not everybody has or uses a scroll wheel and that scroll wheels are an RSI nightmare. That said, I like this thought of yours. It would solve a bit of that RSI problem, although may not fit well with every wheel out there. Keep in mind that newer mice are removing the 'clickiness' and instead going with an approach where the wheel glides very smoothly. Thus, we get a similar effect happening in two places at once. Not that this is impossible, but it would need some fiddling˙ Speaking of repetitive strain, some of the comments to that blog post caused extended sessions of face-palming. There are two groups here I must single out: -Those who say touch screens are the future, thus this is irrelevant -Those who say scroll wheels are all people need, thus scrollbars should be abolished As well as what I just said, scroll wheels are also really not that commonly used amongst general users. I see many people using the scroll bar, just as only power users really use hotkeys. (Much to our horror when waiting for some peoples' workflow...). Touch screens, on the other hand, are begging for a feature like this. The fact is, our current interfaces have a lot of scrollbars. As anyone who has encountered HP's TouchSmart PCs will realize, beneath the shiny finger-friendly interface is the old fashioned mouse and keyboard interface. Yes, it uses scrollbars and small buttons. Those scrollbars are literally unusable; the targets at top and bottom are way too small for fingers. (Looking forward to that size by units patch for GTK!). This solves the issue by essentially raising the clickable area of the scrollbar to be the entire thing. While it does conceal that page up / down functionality, I think it is a worthy sacrifice for streamlining the rest. Having too many buttons in one place causes problems, hence the scrollbar's present sad state. Not that I mind the thought of kinetic scrolling in addition. I think we are in a neat spot for that, since GTK has always used a scroll area container. In theory, it could grab unhandled mouse events to do kinetic scrolling when the user clicks on the child window. (Which, if I recall correctly, is what Matchbox does for moving windows; it can be done when the user clicks anywhere within). Suffice it to say, scrolling is a big thing and it's great that we have such a flexible UI toolkit. It would be fun to put that flexibility to the test. Bye, -Dylan
signature.asc
Description: This is a digitally signed message part
-- Ubuntu-devel-discuss mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
