Re: to implement the iphone-like 'floating scrollbar'

On Jan 25, 2008 6:38 AM, Freddie Unpenstein <fredderic excite com> wrote:

Presumably, you'd make it visible when the underlying range widget complains about being changed, and then 
hide it again after some timeout.

that's what i am doing. the tricky part is how to draw the scrollbar
right on top of the underneath viewport and the widgets contained in
the viewport.

What I'm trying to figure out, though, is how do you scroll a widget, if its scrollbar only appears after 
the content has been scrolled?!?  (And assuming you don't have a scroll wheel on your mouse.)

i used some controls make by openmoko, the basic idea is to cover a
eventbox onto the viewport, and the eventbox would steal the mouse
event and handle the scrolling.

Or are you planning to implement automatic click-and-drag scrolling for the associated content somehow.  
And if you are, what happens if the content has interactive widgets, or drag sources, or whatever else.

at least it works for labels and gtkentry, since press/release events
will be passed to the widget. drag&drop will be in conflict but
hopefully i can disable dnd later.

And are you planning to have the scrollbar just float, or steal some size from the widget as automatic 
scrollbars do at present?  And then if it floats, will the other scrollbar appear also so you can get to 
the content now hidden?  Or does the user just have to sit there and wait until it hides itself again?  And 
who gets to decide how long that is?!?

ideally the scrollbar should just float above the scrolled window.
when it appears, user can just wait until it hides, the timeout will
be pre-determined.

Interesting idea...  Though I can't imagine it being more useful, than hindering, for most computer users.

it could be useful at least for mobile user. since the screen space is
too small to hold the scrollbars all the time.

What WOULD be useful, though, is two individual features;

1) A "click-and-drag scrolling" derivative of GtkScrolledWindow.  I'd make it a derrived widget, since I 
can't imagine how allowing contained widgets to remain interactive could be useful, and an entirely 
separate widget states that much better, plus keeps the two opposing logics clearly separate.

openmoko guys did a great job on this, check this out:

2) A handle box type widget that hides its content until the mouse comes near.  This could be set to either 
float or inline.  In float, you'd display a grip-bar to let the user know that there's something there, and 
then pop-up the contained widget over top (covering but not actually replacing the grip bar) when the mouse 
comes near it.  In inline, you'd replace the grip bar with the contained widget while the mouse was in the 
vicinity, and swap them back when the mouse moved away.

it would be better if both the scrollbar and the stuff in the
scrollwindow can be display'd simultaneously, still does not figure
out how to do it correctly. to float the scrollbar on the widget, the
scrollbar can only be paint after all other widgets are repainted. i
tried to postpone the scrollbar repaint event, it seems works.

Inline mode here, should be easy (except, possibly, for the "in the vicinity" part, if you wanted to allow 
a few pixels leeway).  The underlying widget would take care of the need to present the opposing scrollbar 
where needed.  In the float case, I suppose if you centered the contained widget (there should be an 
alignment setting for this, though) over the grab bar, it would work on that basis of "just deal with it".  

The grip bar in either case would have a minimum size (that of a normal grip bar, square), and would 
usually be extended to fit either horizontally or vertically, by the widget it's embedded within (HBox, 
VBox, or ScrolledWindow, etc.).  The contained widget would, of course, would be expandable similarly.

I've got a helper function presently, somewhere, that adds click-and-drag scrolling functionality to 
widgets.  It'd be interesting to see it absorbed into a real widget.  Although I'd find the popup on 
mouse-near behaviour most annoying personally.


Join Excite! -
The most personalized portal on the Web!

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]