pavel.safrata at oracle.com
Fri May 25 02:04:09 PDT 2012
I believe that by default the scroll pane has to scroll on mouse wheel,
not zoom. A map is one specific example, but if you make a scroll pane
with some text fields and buttons in it, you'd be really surprised if
"scroll wheel" would zoom it instead of scrolling.
Anyway, would you please start a different thread that has something
like "default control behavior" in the subject? I wanted to discuss
multi-touch API and I'm not really an expert on controls.
On 25.5.2012 10:56, Tom Eugelink wrote:
> On 2012-05-25 10:20, Dr. Michael Paus wrote:
>> I like this idea but in this context we should then also support a
>> zoom function. When you can pan
>> a pane you most certainly also want to zoom in and out. This can be
>> achieved by a gesture or
>> via the mouse wheel but so far I have not been able to get that
>> working with a scrollpane.
>> Am 25.05.2012 10:04, schrieb Tom Eugelink:
>>> 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
>>> 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.
>>> Am I making myself more clear?
>>> 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?
>>>> 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.
More information about the openjfx-dev