ups, I made one mistake:
"So both solutions use the real Java platform (=OpenJDK)!“ should be "So both
solutions does not use the real Java platform (=OpenJDK)!“ ;)
Am 24.10.2013 um 08:41 schrieb Tobias Bley <t...@ultramixer.com>:
> Hello to the community,
>
> I read the last discussion about „JavaFX native look and feel“ and have to
> get out of my mind the following:
>
> In my opinion the MAIN point is not „how to bring the native look and feel to
> iOS/Android“, the real MAIN issue is: we need a professional JVM(!) which
> works performant and reliable on iOS, Android and Windows 8! Only if we have
> such a JVM, developers and companies are motivated to develop real commercial
> apps with JavaFX and contribute stuff back to OpenJFX!
>
> RoboVM is a good „prototype“. Niklas is currently one of the most important
> people for the JavaFX community. He and his company has build the first and
> one and only real solution to deploy Java and JavaFX code to the iOS
> platform! His work is really great! But: He is only one(!) person! This kind
> of complex task I would expect from big companies like Oracle, IBM, SAP or
> Twitter. But from this direction we don’t hear anything about it.
>
> It is not enough that people like Niklas (Trillian AB) or Matthias and me
> (UltraMixer) are trying to bring JavaFX to iOS and Android. It’s all
> experimental stuff! Yes, currently we can start JavaFX apps on a real iPhone
> and iPad. And yes, we have managed to start JavaFX on a real Android device
> using the Dalvik VM. BUT: this is not a long term solution and only
> experimental! RoboVM on iOS uses the android class library instead of the
> real Java = OpenJDK. Our „JavaFX on Android“ solution uses Google Dalvik VM
> and the Android class library as well! So both solutions use the real Java
> platform (=OpenJDK)!
>
> In my opinion there are only two solutions: 1) Oracle releases their JVM for
> iOS and Android. 2) The „community“ starts a new company who develops a
> professional, performant and reliable solution for „JavaFX on iOS and
> Android“ which contains of a JVM and the 6 degrees Felix described in his
> blog post, mainly native integration (API) and look and feel (skins, native
> controls).
>
> Cheers,
> Tobi
>
>
>
> Am 23.10.2013 um 22:30 schrieb Richard Bair <richard.b...@oracle.com>:
>
>> 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,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>
>
