Re: Platform.isSupported behavior
Hi Stas, On Nov 19, 2013, at 12:02 PM, Stas Smirnov wrote: > 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? Eventually and after more discussion. From my point of view none of this discussion is about Java 8 - there aren’t going to be any more API changes or non-critical changes to controls behavior in that time frame. Would you open a JIRA for this, targeted at 9? Thanks, Daniel > > 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 >> 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
Re: Platform.isSupported behavior
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 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
Re: Platform.isSupported behavior
> 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. +1
Re: Platform.isSupported behavior
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 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 >
Platform.isSupported behavior
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
