Site navigation

Viewport scrollbar positioning flexibility

General JUCE discussion
#1

Hi!

I’ve a request for changes to how viewport handles its scrollbars that may make sense to include in Juce. I know after searching the forum that the scrollbars in the viewport is something very sensitive to edit, but perhaps this won’t risk breaking anything still!

Now that touch screens are mainstream, the accessibility issue of scrollbar placement becomes important.

Left-handed users (I’m one of them) hate scrollbars to the right of a viewport, because scrolling then means that you hide the viewport content with your hand.

The solution is to have an option in the software, of having all scrollbars to the left instead. Currently, the only way this can be accomplished in Juce is replacing the viewport class entirely, with all the repercussion that has in modifying also all classes that use viewports (treeview, etc).

For a while I just made my own scrollbar, hid the ones in viewport, and re-implemented all functionality by listening to the relevant events in viewport and scrollbar. But then I ran into autoscroll not working, did not know how to fix that, and so gave up on the approach.

Perhaps the most flexible solution would be to allow programmers to manage scrollbar placement themselves completely, but still be allowed access to all relevant events in viewport (e.g. autoscroll)?

To go the furthest possible with this thought, in the most flexible of scenarios which could be useful for more than just leftie-compatibility, a scrollbar could be linked to n viewports, so that for example a ruler viewport could be placed next to a content viewport, and any scrolling within any of the viewports would be propagated to their common scrollbar, and to the other viewports. This would too be nice to have but may be too far out, still, it’s a thought :slight_smile:

Anyway, back to normality: I’ve managed to grab the scrollbar and have it be owned by the containing component, so that it can be re-positioned, but the below code in Viewport’s updatevisiblearea() ruins it for me:

(...)

   if (vBarVisible)
    {
        verticalScrollBar.setBounds (contentArea.getWidth(), 0, scrollbarWidth, contentArea.getHeight());

     (...)
   }

Finally, since I might have missed something, perhaps the functionality I’m asking for is possible and I just don’t know how to do it, making all the above irrelevant?

#2

Good feature request… Annoyingly, positioning the scrollbars is actually far more tricky that it sounds, because their position is different depending on whether vertical and/or horizontal ones are visible (i.e. if both are visible they mustn’t overlap in the corner), and whether a bar is visible will change the size of the content, which… may change the visibility of the bars, etc. in a recursive loop. That’s why there’s a fair bit of hard-coded logic in there, which has taken many iterations to get right!

#3

I don’t like scrollbars on touch screens at all, isn’t the “iOS” way to have the entire rectangular area gesture-enabled for swipes? Scrollbars, to me, seem like a desktop OS phenomenon only.

#4

TheVinn:

Yes and no! In an internet browser window, I’m absolutely with you.

But what do you do when you want to scroll a window full of multi-touch enabled widgets, say for example a window full of faders and knobs, each individually controllable simultaneously with the rest?

When, then, are two fingers on the screen a scroll gesture, and when do you want to move two faders simultaneously?

Because of the above, I think gestures in the context of multi-touch music making apps may not make much sense, and I’d rather waste some screen real estate to implement unambiguous, frustration-free interraction…

#5

I would have to try it to know for sure but my instincts tell me that having a scrolling view full of controls that themselves are operated using the same swiping gestures sounds like a confusing interface. I would try to redesign it in a way where the gestures are not ambiguous. For example, all the faders could be vertical, but the view would might scroll horizontally. Or perhaps a tab strip for selecting which page of controls to modify instead of a scrollbar.

#6

Which is why I went with scrollbars, exactly :slight_smile:

…Because like with many other musical control interface, mine too is packed with knobs, faders, x-y controllers, adsr envelope graphs, and all are supposed to be useable in parallel. And they’re too many to fit one screen, so I want scrolling…

I don’t think gestures will replace widgets any time soon… Not until this stuff jumps out of proof-of-concept-sci-fi-land and actually gets adopted. I give it another 100 years: https://vimeo.com/54027470 , http://oblong.com/what-we-do/g-speak.