mouse vs. touch events on touch systems like iOS/Android/Dukepad
assaf.yavnai at oracle.com
Wed Oct 23 01:18:25 PDT 2013
Please look inline
On 10/22/2013 07:33 PM, Richard Bair wrote:
> Hi Matthias, I think Assaf, one of the embedded engineers, is now on the mailing list and can help answer these questions.
> On Oct 21, 2013, at 1:58 AM, Matthias Hänel <haenel at ultramixer.com> wrote:
>> I believe my conceptual question on touch/mouse events has been missed because of the other questions
>> in the "JAVAFX on ANDROID" thread. That's why I would like to start a new discussion about touch events.
>> 1. The main question is how are touch and internal mouse events handled? Javafx controls seem to rely on mouse events.
>> That's why I assume there must be some kind of an emulation layer. Are these emulated in Prism, Glass (Java-Glasses)
>> or even lower? Where is it suppose to emulate the mouse events?
>> What I've seen right now is that iOS-native glass does the mouse
>> emulation by itself in GlassViewDelegate.m. Touch events and Mouse events are sent from the lowest layer.
>> In Android there are only touch events passed to the lens implementation. On udev which I assume is the implementation
>> that's used for Dukepad it does only pass touch events. Udev and Android are lens implementations so, they are using
>> the same Java classes which do kind of mouse emulation for toch events. But it's not exactly the same as the iOS
>> codes does.
>> sends Touch, Mouse-Enter and Mouse-Down
>> Lens (Android/Dukepad):
>> sends Mouse-Enter and Touch
>> The major differences in calling order and the missung mouse down leeds me to the assumption that the events are actually
Basically the Glass port resbonsible to simulate mouse events from touch
events. On Windows, for example, its done automaticaly by the OS, in
other implementations its emulated in the native layer, in Lens
currently its done in several places and layers (the input driver, the
window manger and the java glass code).
There are currently several issues with the touch support in Lens
implementaion that effects all the ports that are using it.
You can track the work through the master bug RT-32802.
I'm curently working on solving those issues, and one of the fixes is to
make mouse simulation more unified.
Please feal free to open more bugs for specific scenrios and link them
to the master bug, so we can track it and solve it.
>> 2. Is that mouse emulation supposed to be eliminated due to the latest lensWindow changes?
>> I believe that must be handled in higher layers not in the input layer itself.
What do you mean by 'latest lensWindow changes'? please clarify the
>> 3. What is the input layer for the Dukepad? I think it's the udev implementation and this does pretty much the same as the current
>> android implementation. I just want to have a "stable" reference to look at ;)
The input driver, as we call it, is depend on the system you are running
and not the application you are running. From Application prespective
its all the same. So on embedded devices, like the Raspberry PI, it will
be udevInput, on Windows it will be Window's Glass implementation (not
Lens based), on Android it will be Android porting + Lens and so on.
>> 4. Has anyone with a Dukepad the opportunity to test the ListView-Example? For me on Android, it doesn't scroll at all with any touches.
>> With the automatic scrolling (from Richard sources) I get around 30fps on the Samsung Galaxy Tab 10.1.
Again if you find a problem or a bug please open a JIRA against so we
will be able to track and fix it.
More information about the openjfx-dev