Well I guess I am in the "once bitten, a thousand times shy" category after my experiences with Swing over the years.
As I have mentioned in my blog posts, I believe the "native" look-and-feels for Swing were a monumental mistake. The first version of the Swing Windows look-and-feel for example left most people a bit gun shy because it was just so blatantly obviously different from the native OS and even now I don't feel that this look-and-feel is something I would ever want to use in an application I sold commercially. The problem is that is eerily similar to the native UI but sufficiently different to give the user a very uneasy feeling. It still makes a Swing application look like an imposter. One of the most notable issues was when Windows Vista arrived. Prior to then it was fairly easy to render a Windows progress bar in Swing but with Vista came an animated green progress bar that was never properly implemented in Swing. The problems across all controls worsened with Windows 7 and are now at their peak with Windows 8. The fact that Swing supports pluggable look and feels (PLAFs) is absolutely awesome and was quite revolutionary but to extrapolate that concept into making a native look and feel one of those was a huge mistake. The cross-platform PLAFs like Nimbus and even more so Substance that did not at all try to resemble any native UI were by far the best PLAFS to use. So I don't want to see all this repeated with JavaFX. Trust me, mobile/tablet users *will* spot the differences between a native app and a JavaFX app and they *will* be affected by this (especially Apple users). Steve Jobs would never have allowed this to happen and quite rightly so. So for mine, there are only two possible ways forward. 1. Use lightweight JavaFX controls exclusively. This is akin to Nimbus or Substance as a Swing PLAF. Then it's quite clear that the app is not trying to impersonate a native app and there is endless flexibility in the way the controls look and behave. The downside of course is that there can be no native controls used but it may still be possible to integrate the non-visual aspects of native controls like I mentioned earlier. 2. Implement the "layering" scheme where true native components are mixed with JavaFX controls. The advantage is that it will look and behave exactly like a native app with the added benefit that comes from the addition of lightweight controls. Option 1 is the most likely solution and is much easier to implement than option 2. Option 1 is limited in that it wouldn't be possible to utilise any native control rendering which would limit the types of native controls that could be used (iAds for example would be a no go). Option 2 is limited in that the native controls would be rendered by the OS and then the entire solution is limited by the range of transformations supported by the OS and also the degree of visual customisation available. I would really hope we can make Option 2 happen but Option 1 would be a perfectly acceptable way forward as well. FYI, here's my 6 Degrees post: http://justmy2bits.com/2013/09/30/javafx-on-ios-and-android-six-degrees-of-separation/ Felix On 23 October 2013 07:51, 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 > >>> > >> > >> > >
