Yeah, the Swing file dialog is quite embarrassing... I accept that you can ship commercial software using the Swing Windows look and feel but only to certain types of customers and certain market niches. I do not believe you could compete with native applications in a more generic market sector though so I do not feel it is viable for most software houses.
And that's what I am talking about here. Sure, we can get JavaFX for iOS and Android out the door and sure we can build pretty nice apps. But I want to be able to compete with the "big boys" and sell *serious, high-quality commercial software*. My dream is that JavaFX will enable me to do that. On 23 October 2013 08:44, Scott Palmer <swpal...@gmail.com> wrote: > +1 for native keyboard support. Unless you want to emulate the dictation > feature in iOS and all that kind of stuff, you pretty much have to use the > native keyboard. > > But I think native widgets in general could be postponed, so long as JNI > could be used to implement settings and the sort of thing that would be > expected to have a lot of "standard" controls. Often in the main part of > the app on iOS the UI is very customized anyway. I do ship a commercial > app with Swing and the Windows LnF and except for the file dialog, nobody > cared. > > Scott > > > On Tue, Oct 22, 2013 at 5:20 PM, Felix Bembrick <felix.bembr...@gmail.com > >wrote: > > > 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 > > > >>> > > > >> > > > >> > > > > > > > > >
