Multi-touch API

[Pavel Safrata]

Tom,

On 25.5.2012 10:04, Tom Eugelink wrote:
> It's about default behavior and uniform UI. Naturally everyone can 
> code their own dragging, but it would be great if certain things came 
> out of the box. If you pull a ScrollPane from the toolbox, it is 
> default setup to scroll by using the scrollbars. This is not the way 
> this is done when using touch, then you would use a drag. So there is 
> a difference between the default behavior.
>
> I found that I'm preferring to use the touch behavior when navigating 
> with the mouse as well and actually am annoyed when I need to click 
> the scrollbars. So I am trying to make a point to maybe get the mouse 
> and touch behavior as similar as possible. This would mean that, for 
> example, a scroll pane would default run in the pannable mode (I'm 
> ashamed to admit that I have not done enough JFX UI to know that it 
> existed).

I guess we may consider making ScrollPane pannable by default, but this 
is an entirely different discussion. I'd suggest you file a feature 
request on Controls for the responsible engineers to consider. In this 
thread please let's stick with reviewing the multi-touch API.

>
> My discussion about the marker example is to indicate that I 
> understand that making a the scrollpane pannable, may cause problems 
> when there are things inside the pane that also want to drag. But 
> maybe it is possible to have the scrollpane first check if there is 
> any contents that would like to react to the drag, and if not then the 
> scrollpane itself can process it.

As I tried to write earlier, you can put your node in the scroll pane, 
handle dragging in it, and if you consume the event it doesn't bubble up 
to the pane. So there should be no need for such checks, you can easily 
decide which nodes will consume the dragging and which nodes let the 
pane be dragged.

Thanks,
Pavel

>
> Am I making myself more clear?
>
> Tom
>
>
>
> On 2012-05-25 09:49, Pavel Safrata wrote:
>> Hello Tom,
>> I think I didn't really get the issue. You can install mouse dragging 
>> event handlers on the map and on the marker. Why is that not 
>> sufficient? Or do you want that specifically for our ScrollPane? 
>> There is a "pannable" property that makes the scrollpane react on 
>> mouse dragging. If you register a dragging handler that consumes the 
>> event on any of its children, it is not propagated to the pane, so it 
>> doesn't scroll. Is that insufficient?
>> Thanks,
>> Pavel
>>
>> On 24.5.2012 16:37, Tom Eugelink wrote:
>>> The topic is too complex for me to provide any reasonable feedback 
>>> at this time.
>>>
>>> I do have a question though; I find myself dragging scrollpane 
>>> contents with my mouse lately, mimicking a finger slide, because it 
>>> feels very natural to do. Google Maps does support this kind of 
>>> navigation with a mouse (you can drag the map around), but a lot of 
>>> applications do not, and one has to go to the scrollbars and start 
>>> clicking. I understand that this actually makes sense, because the 
>>> contents of the scrollpane may want to react to dragging. Google 
>>> Maps solves this by differentiating where you click; on a marker 
>>> (drag in the pane) or on the map (drag the pane itself). It may be 
>>> efficient to have cross platform interaction to have viewports 
>>> support this difference in UI and allow a mouse to work like a 
>>> finger. Just braindumping.
>>>
>>> Tom
>>>
>