The Next Great Thing: An Application Framework (original) (raw)

Daniel Zwolenski zonski at googlemail.com
Tue Feb 14 02:26:31 PST 2012

I think the below was intended for the discussion forum as a whole but came direct to me so I'm resending. I will respond with comments in a separate email.

On Tue, Feb 14, 2012 at 5:54 AM, Jeff McDonald <deep.blue.6802 at gmail.com>wrote:

Some of the conversation is clouded by the vague meaning of an "Application Framework." Dumping something like Eclipse or Netbeans into JavaFX is like bringing a nuke to a spit wad fight. Maybe by giving the project a different name might help avoid some of the confusion ... how about calling it an "app kernel." Honestly, the name isn't that important, but the term is more descriptive. What an app kernel should be is a small layer that sits between the world outside of the app and all of the components inside the app. Another descriptive name could be "Application toolkit."

Interestingly, the app framework discussion came about as a discussion Richard and I were having about the Application menubar. In JavaFX 2.1 the way to set an application menubar is to call some method such as "useApplicationMenuBar(boolean)" then, magically the menu from the focused window show up in the Application menbar. This design opens the door to lots of inconsistent behavior. For instance, if each menubar has an "open file" menu item then duplicate code might be required or the code could be centralized, but if the action requires a knowledge of of which component (or selected item) has focus then the solution becomes more complex. In short it makes development much easier when there is something above the window level to both unify window to window interactions as well as OS to application interactions. I am willing to put code and time into an app framework as well. Here are some of the core level things that would make for a compact efficient App Kernel: 1. Provide a single point of abstraction for window to window interactions 2. Handling application targeted events.Receive and send OS to application events / messages 3. Provide application context information. A single point of access to query and interact with settings and environment information. Some of the information would be architecture specific, but not limited to such information. For instance, calling getRenderingPipleline() would return the rendering engine that JavaFX is using. That choice is made at runtime and based on other native and non-native conditions. 4. Provide commonly used functionality to simplify application development and promote basic greater consistency for standard application functionality. Random thoughts about aplication level events: - Component targeted events are already handled by JavaFX, however, there is no means of handling application targeted events such as a "Quit" command that is issued through the OS. You can call it an eventbus, or messagebus, or an App.handleEvent(Event) singleton or whatever): 1. Windows, macOS, iOS, and Android support them for handling system calls for closing down an App, opening documents, going into hybernation. Those are events that are already in the OS's. Can you write your own code to handle this? Yes, but that's like saying there's no need for adding XML parsing because Java already handles strings. 2. How does a developer "quit" and application? Is it when you close a window? In a single window environment on the Windows platform it (typically) means quit. On the Mac it means dismiss the window, but the app is still alive (oops ... no calls to System.exit() on WindowClosed event if you want to be Mac friendly). In a multi-window environment it could mean many things. On a mobile platform moving to a new window (or rather a page) means just changing context. On a mobile device the "quit" action or event comes from pressing a physical button on the device. Where is the support for "quit" in JavaFX? 3. ScreenOrientationChangeddEvent - This is an application level event that should be handled above the window level. On Sat, Feb 11, 2012 at 10:59 PM, Daniel Zwolenski <zonski at googlemail.com>wrote:

I like all the thinking on this front and the different initiatives (and the enthusiasm). I think there is a lot of room for us to exchange ideas (and code!) and either make sure each of the platforms is doing something unique, or merge efforts if they are not. One of my fundamental goals however is to not tie a developer into a specific development toolset/environment as much as possible (as a developer I hate it when I can't use my tools, so I try to make it so everyone else can use their weapon of choice too), so the frameworks based around Eclipse (or any specific IDE) are unfortunately not of direct appeal to me.

Having said that, I'd love to keep abreast of the features being added, how they are being implemented, architectural patterns and motivations, etc. Perhaps there is even room for a project like JFXtras to become a spot for us to put common toolkits that our frameworks can all share, rather than each of us reinventing wheels. If there is anything in JFX Flow that people would like to use in their toollkits, let me know and we'll see if we can section stuff off. Likewise I will look through your frameworks as much as time allows and see what overlaps (e.g. maybe we could all work on a form validation framework together that our application frameworks then share and add to, etc). Richard, on the topic of what the JFX platform should/shouldn't include, can I add another way of thinking into the mix for you to mull over: although there is a strong case for keeping the JFX platform as the 'core' library, just because other modules/elements are not part of the 'core' doesn't mean that Oracle can't produce them, sponsor them, contribute to them, etc. It would be great to see Oracle champion initiatives on each of the logical extension fronts (full app frameworks, game platforms, form/wizard frameworks, navigation/event-bus libraries, high-level animation libraries, PDF/doc browsing/editing, voice/video conferencing, etc). This approach would achieve the goal of getting all these needed value-add frameworks built in a consistent, 'official' way, but would remove the restrictions implied by a core framework (e.g. can't use 3rd party, tied to core release timeline, legal issues, etc). Also the cost to Oracle would be massively reduced, allowing them to achieve far more with limited resources. If Oracle is driving initiatives they can still keep their brand on it - Google uses a similar approach and it only adds to their brand and their platform (see http://code.google.com/). In some (few) cases this could be in the form of Oracle putting together it's own closed team (like the JFX team is now) on a project if Oracle feels that area is of critical importance/urgency to the JFX platform. My preference however would be for Oracle to instead either lead or support open source community efforts. Perhaps by providing a project lead for it and getting members of the community to sign up and join in (perhaps even sponsoring some community developers - like a 'key contributors' model or something). Alternatively (or as well) it would be awesome if Oracle had an internal, dedicated team of 'community supporters' who's full time job it is to assist community projects that Oracle sees as value add to the platform. This team would help guide/support projects that look to add value to the JFX platform, possibly by providing direct development resources, or otherwise by providing publicity, official 'sanctioning', infrastructure/hosting support, and communication links to funnel requests back to the JFX team for core support/enhancements, etc. Additionally this team could also help identify duplicate efforts and try and foster/guide collaboration and effort-merging to limit the number of similar initiatives (for us garage developers working out how to collaborate is a lot harder than it sounds, and having a trusted third-party assist with this would be useful). In a better world, the java.net developers site would be the ideal infrastructure for these sorts of projects, but unfortunately (in my opinion at least) it is a dog's breakfast of a system with a horribly unusable UI, outdated/limited features and poor performance. I've tried to use it in the past and found it too painful and ended up switching to google code. If some energy were to be expended on making java.net more like a modern day collaboration suite (the Atlassian toolset for example) then this could be the perfect platform for this sort of community effort, all to the mutual benefit of Oracle and the JavaFX community as a whole. Win-win. For what it's worth, I would volunteer what spare time I could find to work with guys on your end to make something like this a reality.

On Sat, Feb 11, 2012 at 8:55 AM, Tom Schindl <tom.schindl at bestsolution.at_ _>wrote: > In my thinking is an IDE is simply a large large RCP-Application? > > In this sense like you as an die hard Eclipse users I've started > developing an RCP framework built on top if Eclipse 4 Application > Platform which provides the completely new runtime layer the Eclipse 4.x > IDE is built upon. > > The key things are: > * extensibility by using OSGi > * event bus built on OSGi Event Admin > * service architectur built on OSGi > * theming via CSS > * programming model based upon JSR 330 (javax.inject) > * DOM like Application Model providing clean seperation between > application state and rendered UI > * commands/handler framework > > Kai Tödter is also doing work in this area (he also builds on the > Eclipse 4 Application Platform) and has published nice screenshots of > applications [1]. > > I'm currently working on a demo application which we'll demonstrate at > Eclipse Con North America in March showing how a collabrative > application can be built using the Eclipse 4 Application Platform and > JavaFX (because it's at EclipseCon we'll even mix SWT into the game but > that's a minor thing) [2]. > > Coming back to my above assumption that an IDE is nothing more than a > big RCP application - the RCP the framework built by us - can easily be > expanded to an IDE e.g. by mixin in other Eclipse technologies like e.g. > JDT-Core, Xtext for DSLs, ... . > > I think the important thing for efx and the e(fx)clipse runtime > platforms is that they build upon hardened frameworks because other big > products (Netbeans and Eclipse) are built upon them. > > This makes those 2 frameworks share resources with others (e.g. > e(fx)clipse runtime platform currently has around 20 classes and > supports all important UI paradigms starting from menus to toolbars to > tabs) while inheriting all other features from the framework developed > at Eclipse. > > BTW if you are not happy with the UI-Paradigms currently defined in the > Eclipse 4 Application Platform you are able to expand and mix in your owns. > > All our sources are provided under EPL [3]. > > Tom > > [1] http://www.toedter.com/blog/?p=709 > [2] > > http://www.eclipsecon.org/2012/sessions/eclipse-4-meets-cdo-now-you-see-it-and-so-do-they > [3] http://github.com/tomsontom/e-fx-clipse > > Am 10.02.12 22:00, schrieb Sven Reimers: > > Seems there is more than one approach out there for getting a JavaFX RCP > in > > shape. As a die hard NetBeans RCP user I started an open source > > java.netproject called efx, which tries to reuse a lot of the NetBeans > > RCP pattern > > while getting rid of the Swing UI. > > > > So the focus is more on RCP not on an IDE or something similiar, but with > > first class support for development of such RCP based applications.. > > > > Sven > > Am 10.02.2012 21:35 schrieb "Richard Bair" <richard.bair at oracle.com>: > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl geschäftsführer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 >

More information about the openjfx-dev mailing list