Hi Daniel,
about caching, I placed it in the list, because there is no spec telling
about it, and anyone can add/remove it, that why it is an object of concern.
It will be great to hear from Controls team, cause from my point of
view, dynamical change of controls behavior will improve usability.
Talking about ObservableBooleanValue, nice idea, I think it will be
really better, than having boolean return value. Are you going to
implement it?
19.11.2013 13:32, Daniel Blaukopf ?????:
Hi Stas,
Yes, you have a good point here. The behavior you are seeing is what I
would expect, but I agree we could do better in how we specify this.
Currently,
* States reported by Platform.isSupported are updated when input
devices are added and removed
* Controls check the connected input devices at startup time. They
do not change their behavior on the fly as input devices are added
and removed.
Enabling listening to state changes certainly makes sense - probably
by defining state in ObservableProperties. I’m not sure we actually
want controls to reconfigure themselves dynamically and automatically
though. Maybe someone working on controls can comment on this, but it
seems like it would be a complex transition with many edge cases to
deal with.
Why change caching of input device state in Lens and Quantum though?
Lens needs to cache the state of input devices in order to be able to
report on what input features are available. I’m not sure Quantum is
doing any caching of this state at all - as far as I know it is going
directly to Glass to query input device features. Controls do of
course cache input device state.
A thought about API for listening to state changes. What if we added
an API to Platform like Platform.isSupported that instead of returning
a boolean returned an ObservableBooleanValue? This listener would
never be notified on conditional features like EFFECT or SCENE3D but
would be notified on those conditional features that reflect input
device state.
Thanks,
Daniel
On Nov 19, 2013, at 10:09 AM, Stas Smirnov
<stanislav.smir...@oracle.com <mailto:stanislav.smir...@oracle.com>>
wrote:
Hello,
Lately I have faced a strange behavior while I was using JavaFX
Embedded and touch screen.
As far as I understand there is no spec where I can find this
information, that is why I decided to ask the community.
I have developed a simple application with one text field and a
button. I run it using JavaFX Embedded runtime with LCD+touch monitor
connected to an abstract board.
As a result I can see touch mode in the application, the virtual
keyboard and other touch features. However if I plug out the touch
part, connect mouse, at the runtime, the application does not change
its appearance and behavior, the vk is still available with all touch
features. So only restart of the application disables touch mode.
I know that there is Platform.isSupported method to detect different
states, and touch is one of them. So I have checked, that, when I
during the runtime plug in/out touch and press the button to check
Platform.isSupported value, I can see it changes every time I plug
in/out the touch screen.
I assume it happens, because every time I call Platform.isSupported
the real check is being performed and because of that its value
changes. But once again, there is no spec to check it.
I have a proposal:
* what if there will be some kind of listener to handle state changes
* add this listener to the controls where they ask
Platform.isSupported to make controls change their appearance and
behavior
* disable caching of the state in the platform(lens, quantum)
* create specification where the realization will be described
--
Best regards,
Stas Smirnov
Stas Smirnov | Java Embedded
Phone: +7 812 3346130 | Mobile: +7 921 9262241
Oracle Development SPB, LLC
10th Krasnoarmeyskaya 22A, St. Petersburg, 190103, Russia
--
Best regards,
Stas Smirnov
Stas Smirnov | Java Embedded
Phone: +7 812 3346130 | Mobile: +7 921 9262241
Oracle Development SPB, LLC
10th Krasnoarmeyskaya 22A, St. Petersburg, 190103, Russia
