Matthias,

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.

Thanks
Richard

On Oct 21, 2013, at 1:58 AM, Matthias Hänel <hae...@ultramixer.com> wrote:

Hi,


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.

iOS:
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
missing.
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. <https://javafx-jira.kenai.com/browse/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 question.


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.
I didn't.
Again if you find a problem or a bug please open a JIRA against so we will be able to track and fix it.

Thanks,
Assaf



regards
Matthias


Reply via email to