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 <[email protected]>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 <[email protected]> > 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 > > <[email protected]>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, > >>> > >>> > >>> > >> > >
