Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
There are a few critical elements that must conform to platform-specific look and feel: - app installer - management of app icons - system dialogs: file open, save and save, print - os x system menu bar Apart from these elements, native look and feel should be optional. On Mon, Dec 9, 2013 at 12:31 PM, Felix Bembrick felix.bembr...@gmail.com wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry
Re: JavaFX on iOS and Android: The real problem and challenge
There is more to this issue than simply JavaFX, iOS and Android. There is a bigger picture here that involves the complex relationships between Oracle, Apple and Google. I think it is fair to say that we all have enormous respect for Richard Bair and his team. It seems to me we should listen to Richard. If I understand his postings correctly, he is saying that we, the community, should create a new OpenJDK project which, if it used the OpenJDK class libraries would let his team put support directly into the OpenJFX build system for building FX and running FX apps ... directly on RoboVM. It seems to me that the message here is that Oracle is totally willing and able to support RoboVM as an OpenJDK project. Niklas - are you up for it? The optics here are important. The project must be created by the community (NOT BY ORACLE). from Richard's post of October 22: Personally I'm interested in RoboVM on Android, so that there is a single VM across both iOS and Android. Also if RoboVM supported the OpenJDK class libraries, it would make this so much simpler for us and provide a consistent story. For example, the OpenJFX project is an OpenJDK project and we really can't be officially promoting a VM that doesn't implement the Java standard. It puts us in a very awkward position. If RoboVM used the OpenJDK class libraries instead of the Android class libraries, not only could I push it at conferences like JavaOne, but I could also put support directly into the OpenJFX build system for building FX and running FX apps (like Hello*, Modena, Ensemble, etc) directly on RoboVM without developers having to setup anything special. This would be huge for making it easy for people to contribute iOS fixes to OpenJFX. But I can't do that if RoboVM doesn't actually implement Java. and, from November 8: Totally, I think the normal process for this is to create a new OpenJDK project, is it not? Can you take a look at the OpenJDK bylaws and report back on the process? I think it would be awesome to do a port. Note that there are a few OpenJDK ports already which have ARM support, you might want to look there as a starting point? On Sat, Nov 9, 2013 at 8:59 AM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: I'm sure the javafx team is doing a great job. My intention was not to put that in question but to try to contribute further to this discussion. Yes indeed oracle javafx team has fewer resources than what should be preferred. We need to harvest the power of the community in the best way we can to further expand the this resources. In that sense I think the best to do is to get better organized at doing so. Instead of a man for himself kind of effort we should have a kind of corporate like structure with the intricacies of being a group of volunteers... On Nov 9, 2013 1:21 PM, Felix Bembrick felix.bembr...@gmail.com wrote: What we do know is that Oracle are working on something and that RoboVM is already out there. We also know that RoboVM has serious limitations such as being based on the Android class library, not supporting JDK 8 or OpenJDK or invokedynamic etc. so is not really a viable solution at this stage. This is not to say that the work of Niklas is not first-class as it clearly is an awesome technology even in its current form. I think the key factor we need to consider here is that RoboVM is essentially a one person project and even the JavaFX team at Oracle itself is not that large. Although it's difficult to gauge exactly how many are on the team, I would say from the various names that pop-up on the OpenJFK list and in private conversations we are possibly looking at a dozen or less active staff and possibly a total head count of developers in single figures. Clearly then, with such a small pool of talent, it is not practical to dilute the effort over more than one project. In an ideal world where we had two or more projects backed by large corporations with infinite resources then the more competition would be helpful for long term viability and quality. But our world is hardly ideal and it makes sense to have everyone on the same page. To this end I tend to agree with Pedro DV in that we need Oracle to come clean and open up the porting of JavaFX to iOS, Android and any other potential OS. I am not going to comment on whether Oracle are doing a good/bad job as I am sure there are many more factors and issues that we are not privy to that prevents them from doing exactly what we would like them to do. They are not out to derail JavaFX and in fact are very much behind it being viable on mobiles and tablets. I know Richard Bair and I have to say that he is one of the most passionate developers and believers in Java and JavaFX there is so I am sure he is keener than anyone for it to succeed on all platforms. Perhaps we have to approach Oracle with positivity and a willingness to help and hope that they are in a position (technically/legally/etc.)
