Ok, I have read your "6 Degrees…" publication, and I have to say I agree wholeheartedly with points 2 - 6. I just don't see why 90% of the common set of gui widgets, rock solid dependability and performance isn't good enough? Maybe others disagree I don't know… but if it comes down to being an engineering nightmare or so complex that the dependability or upgradeability is not there, then I just don't see it as important enough to warrant the abandonment of the effort?
Regards, David On Oct 22, 2013, at 3:51 PM, David Ray <cognitionmiss...@gmail.com> wrote: > I think you may be facing an "absolute" requirement which is placing demands > on you to > replicate the exact look and feel of one or both mobile environments? I'm not > sure?? > >> 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 do not see the problem with the above? Yes, the controls in question > would maybe > act differently than their native counterparts and Yes there may not be the > exact complement > of controls each native platform has, but my reaction to that is… so what? > The fact is, > these controls are born of a different gui toolkit. This only is a problem if > one has it "stuck" > in their head that JavaFX has to behave <em> exactly </em> like the native > platform - > I don't see why this is necessary, especially when the variations are minor > behavioral > aspects anyway? The CSS skinning in my opinion is to most closely approximate > the native > look and feel IMO. I just don't see why it is necessary to reproduce the iOS > toolkit or the Android > toolkit in JavaFX? > > This to me is a way to ensure rigidity and lack of movement. As long as > what *does* exist > is rock-solid, dependable and very close looking - then I say good enough. > Otherwise, why not just use > Objective-C or Android?? It is way better to have vertical movement and > obvious progress, IMO. > > I did find the link to your "6 - degrees…" publication - and I vow to read it > in case my opinion comes > down on the "misguided" side of things, but I just don't see the need for > such a tight constraint??? > > Regards, > David > > > > On Oct 22, 2013, at 3:26 PM, Felix Bembrick <felix.bembr...@gmail.com> 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. Then there's the issue that every time the OS changes and the >> behaviour or appearance of those native controls changes, the author of >> those JavaFX controls has to react accordingly. >> >> The issue of keyboard type and layouts is mentioned in my 6 Degrees of >> Separation post and is critical. There's just no way we are going to get >> away with any kind of text control that does not support all the native >> features of entering text on mobiles and tablets. Whether we place a >> borderless native text box inside a JavaFX shape or just integrate the >> native control itself, this is one of the most important features for a >> JavaFX app and one where it would fail spectacularly if this native support >> was not in place. >> >> I know some excellent work has been done on OS skins like AquaFX but >> appearance is only half the challenge. As I said, it's the behaviour that >> will kill us. To attempt to emulate all native control behaviour in >> lightweight controls is not only nearly impossible but in my view it's a >> massive waste of effort if it is somehow possible to integrate the actual >> native control itself. I am hopeful that the "layering" paradigm will >> gives us this. >> >> Another issue though is that native controls are unlikely to be as >> "skinnable" as JavaFX controls and are probably more limited in the scope >> of the customisation of their appearance. Integrating native controls may >> then impose limitations on the richness of the interface as it mandate an >> LCD approach so that the native controls don't look out of place. >> >> To me, the ideal solution would be to just extract/integrate the non-visual >> aspects of native controls (such as the auto-complete, keyboard >> customisations, other behaviour etc.) and then render them with the JavaFX >> API/scenegraph. >> >> >> On 23 October 2013 05:22, Stefan Fuchs <snfu...@gmx.de> wrote: >> >>> Hi Richard, >>> >>> I currently try to release updates of the jfx78 back port in 1-3 days >>> after >>> https://bitbucket.org/**openjfxmirrors/openjfx-8-**master-rt<https://bitbucket.org/openjfxmirrors/openjfx-8-master-rt>(from >>> whereever this comes from) has been updated (usually every Friday). >>> This obviously depends on the number of changes required and my available >>> time. >>> >>> Stefan >>> >>> >>> 2) After starting RoboVM JavaFX needs round about 10 seconds to start the >>>>> simple list example on iPhone4. So it’s too long. I tried to use the >>>>> preloaded class via property „-Djavafx.preloader“ but it doesn’t work, my >>>>> preloaded class is not instantiated… >>>>> >>>> What is the state of the jfx78 back port, and how often is it updated? >>>> I'm wondering what the time is for getting a fix put in before it shows up >>>> in the back port. >>>> >>>> Richard >>>> >>> >>> >
