Yes, definitely.
> On Oct 23, 2013, at 11:52 AM, Scott Palmer <swpal...@gmail.com> wrote:
>
> This is starting to sound like it may also partially address the issue in the
> desktop space of supplying a native surface (the heavyweight) to draw in that
> is part of the scene graph. It may not be the ideal solution, but could be
> useful for specific use cases, like a video preview overlay. Would that make
> any sense?
>
>
> Scott
>
>
>
>> On Tue, Oct 22, 2013 at 7:59 PM, Richard Bair <richard.b...@oracle.com>
>> wrote:
>> To do this we need to either solve the auto-layer problem in the NG nodes /
>> Glass / Quantum, or we need to ask the app developer to use SubScene and put
>> all the native stuff in a single SubScene, and all lightweight content above
>> and below it. For the short term, we could use the SubScene approach ("Just
>> be careful and don't draw lightweight on top of heavyweights unless you
>> layer an entire sub scene above them") which is probably a perfectly
>> workable solution in the short term. Then somebody just needs to write a set
>> of skins (which can be done in an external project) that map various UI
>> controls directly to native controls. This approach would allow people to
>> have completely native controls while using the FX API, or they can use the
>> lightweight controls (with Modena or with an iOS 7 skin or iOS 6 skin etc).
>>
>> I'm thinking about how to implement the auto-layer, and I'm not sure of the
>> best approach. It seems like you need to hook into the sync-time to
>> determine which nodes can be batched into the same layer, reusing previous
>> layers where possible. If there is a way to then setup the NG peer side so
>> that it thinks it was setup in sub scenes etc, although it really wasn't,
>> then that would leave prism out of the problem (which makes this an easier
>> thing to pull off). hmmm. SubScene itself has a peer. So what I'm thinking
>> is, suppose I have a package:
>>
>> com.sun.javafx.ext.ios.controls
>>
>> and in this package you have all the skins. There is also someplace in here
>> a map of skin -> sub scene peer, indicating which of the nodes is in which
>> sub scene peer ("layer"). Then when the sync takes place, a skin node looks
>> back at siblings etc to determine if it can be placed in the same layer as
>> something before it. If so, then it sets itself as a child on the sub scene
>> as needed. If not, then it creates a new sub scene peer and sets itself on
>> there and then carry on. So then it isn't sync'd to the "real" scene but
>> instead to one of these fake sub scenes that was created.
>>
>> The idea can be refined, but actually I think this approach might be
>> workable for doing auto-layering.
>>
>> Richard
>>
>> On Oct 22, 2013, at 4:10 PM, Felix Bembrick <felix.bembr...@gmail.com> wrote:
>>
>> > Yes, having viable implementations of both options would be ideal.
>> >
>> > How long till Oracle and/or the community gets to that point? ;-)
>> >
>> >
>> > On 23 October 2013 10:06, Stephen F Northover
>> > <steve.x.northo...@oracle.com>wrote:
>> >
>> >> Rather than arguing this point, the correct answer is to provide both and
>> >> let the application developer choose.
>> >>
>> >> Do you guys know how old this argument is? Hint: It predates Java.
>> >>
>> >> Steve
>> >>
>> >>
>> >> On 2013-10-22 6:17 PM, Pedro Duque Vieira wrote:
>> >>
>> >>> Even the most fab skins or CSS is not going to get us away from the need
>> >>>> to
>> >>>> integrate JavaFX controls with true native controls. As has been
>> >>>> pointed
>> >>>> out, there are some native controls on both iOS and Android for which
>> >>>> there
>> >>>> is no JavaFX equivalent and this will always be the case. Even if
>> >>>> someone
>> >>>> were to develop near identical lightweight controls in JavaFX, they
>> >>>> would
>> >>>> need to behave slightly differently on iOS than they do on Android and
>> >>>> vice
>> >>>> versa.
>> >>>>
>> >>>
>> >>> I don't think this is exactly this straight forward. Ideally you would
>> >>> want
>> >>> to have this kind of native behavior on every platform. But having this
>> >>> native behavior involves having a different version of your app for each
>> >>> OS
>> >>> you want to deploy in, which might not be what the developers want.
>> >>> Remember JavaFX is a cross platform development kit and the major reason
>> >>> a
>> >>> developer would choose JavaFX over doing native mobile development is
>> >>> that
>> >>> his app can run on a variety of mobile platforms: windows 8, ipad,
>> >>> android,
>> >>> iPhone, etc with the same code base and *MOST* importantly with much less
>> >>> development time than building an app for each platform.
>> >>> For the sake of development time an app that doesn't go against any of
>> >>> the
>> >>> different platforms UX but that has the least common denominator so that
>> >>> each user in each different platform understands the UI might be a better
>> >>> solution for the sake of development time. One such example is the back
>> >>> button that appears when you drill down a list on an ios app but doesn't
>> >>> appear in an android app because every android phone as a physical back
>> >>> button.
>> >>>
>> >>> I do agree with you that there are some places where a native looking
>> >>> control is ideal and doesn't involve any extra effort from the developer
>> >>> to
>> >>> customize it for the given platform like for instance comboboxs where a
>> >>> kind of wheel appears where the user can choose an option, or input
>> >>> controls where the native keyboard pops up.
>> >>>
>> >>> Thanks, best regards,
>> >>>
>> >>>
>> >>>
>> >>
>
