Scrolling a list

[Carsten Haitzler (The Rasterman)]

On Fri, 21 Mar 2008 17:00:30 +0800 Tick <tick at openmoko.com> babbled:

> Hi Raster,
>     I used ETK tree and vbox to make list and put them into assassin as 
> you suggested.
> After thinking about how to make the list scrollable by finger, I have 
> to following ideas.
> 
> 1.     Let the vbox catch events and decide if it is a scrolling event 
> and scroll the tree.
> 1.5                                  Or sending wheel event to tree.

you want the scrollview to catch this. evas allows for objects to repeat events
- that means the object gets an event then it "repeats" to objects underneath.
this is a great way to listen to events by placing an invisible rect over
something else. e17's scrollframe did just that - thats why it could then
scroll everything that was inside a scrollframe via thumbscroll. it got the
events and then would be able to set flags on them (as it got them first) and
do the scrolling if needed on move events as the scrollframe is the controlling
widget for scrolling. the vbox is probably the wrong place. etk would want this
feature - like scrollframe in e or in ewl.

> 2. Let Window Manager knows that press and drag up/down is a wheel event 
> and send the event to the object that pressed.

can't be done :/ (presses are grabbed to 1 client only. you'd disable the
ability to have simple presses or drag & drop, drawing programs and more).
wheel also is inaccurate for this even if it were possible. this has to be done
 in-widget.

> For the first idea, each application will have to manage their own 
> behavior themselves, but I think it is not hard to implement.
> 
> For the second idea. This will also defines the whole user experience of 
> NEO. Like press and drag right may equals mouse right key clicked , and 
> drag up means wheel rolls up for instance.

sure - but in what context. what if i actually want to drag something to the
right? or i am in a drawing/sketch program and want to draw? the wm knows
nothing of the context - what parts of an app "window" do what. :(

> If you choose the second choice, we can base on this behavior and 
> designed our own usage experience.  And some old GUI applications 
> designed for mouse  and desktop interface may behavior strangely.

a lot of things will :( #2 is pretty much not a doable thing... UNLESS the wm
knows what parts of any app window do what (this rect here is a scrollable
region, this here is a button, this here is something else etc.)

> Do you have any suggestions, or better idea?
> 
> Thanks,
> Tick
> 


-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>