(was: The Next Great Thing: An Application Framework)

[Richard Bair]

> Putting that topic aside, I agree that your "app kernal" concept is what
> JFX should include and focus on, i.e. the low level plumbing that a
> higher-level application framework can build upon.

I agree, lets focus in on this first.

>> 2. Handling application targeted events.Receive and send OS to application
>>> events / messages
>>> 
>> 
> This does sound like something useful but I'm not too clued up on what sort
> of OS events we might be able to send/receive? You list a few in your
> "random comments" below. I'll relist them here:
> 
>   - System is exiting
>   - System is suspended/resumed
>   - Screen orientation has changed
>   - System has signalled that a document is to be opened (for which this
>   app is registered as the handler for the extension type)
> 
> Is that what you mean here, and is that pretty close to the full list, or
> are there a whole lot more (working in Java land has left me a little vague
> in knowing what signals the OS can send an app)?
> 
> If it is just this sort of list then I'd like the idea of just having a way
> to register listeners for these via the Platform class. Either a 'system'
> event bus with event types, or individual listener lists for each event
> type.
> 
> So something like:
> 
> Platform.systemStatusProperty().addListener(ChangeListener<SystemStatus>
> listener) // where SystemStatus is an enum of active, suspended, etc
> Platform.screenOrientationProperty().addListener(ChangeListener<ScreenOrientation>
> listener)
> Platform.setOnOpenDocumentRequested(EventHandler<OpenDocumentRequestEvent>
> listener)
> Platform.setOnSystemExitRequested(EventHandler<SystemExitRequestEvent>
> listener)
> 
> Or
> 
> Platform.getSystemEventChannel().addListener(SystemEventType type,
> EventHandler<SystemEvent> listener)

The idea is that these lifecycle events would actually be added to the Application class itself. Some lifecycle is already there "start" and "init" and "stop" for example.

>> 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.
>>> 
>> 
> Being able to find out anything and everything about our JFX runtime
> environment would be extremely useful. I would have thought the 'Platform'
> class would be the logical place for these sorts of things too. So I could
> call Platform.getRenderingPipeline(), Platform.getJavaFxVersion(), etc.

+1

I had thought about also making this the place to get other information or APIs such as Bluetooth support or Accelerometer support, etc. You could ask questions like "does this platform support a Camera?" and then you could get a reference to the camera and call API on it etc. I prefer this to having static methods on various far-flung classes. The downside is that it breaks modularity a bit, but I don't thinking having a dozen APIs here (with no implementation) is such a big loss. The implementation for these APIs (camera, bluetooth, accelerometer, GPS, etc) would all be in separate modules.

>> 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?
>>> 
>> 
> There are definitely cross platform challenges here with things like
> multi-window support, OS-level toolbars, system trays, task bars, etc. Java
> will always suffer somewhat on this front because it is trying to work on
> every platform. Within a window the OS is generally "hands-off" and we can
> do what we like but when were dealing "outside" the window, we're in
> OS-controlled land, the OS gets very involved and wants things done a
> certain way.
> 
> For a cross platform application, the choices really are:
> 
> 1. Support least-common-denominator functionality. i.e. just handle one
> basic solution that works on all platforms and does nothing fancy. If the
> OS does something funky (like Mac does) just not support it - this is the
> AWT model, simple and safe but obviously not ideal usability.
> 
> 2. Try and do some magic stuff (like with the useSystemToolbar() thing in
> 2.1), where the developer in theory can just write code once and the JFX
> platform will do the stuff needed to map that code to what's needed on that
> platform. This is a noble goal, but somewhat dangerous as the little
> idiosyncrasies of each platform generally require more than just moving a
> toolbar from the left to the right, etc. Getting it right is very hard
> (which is why AWT was ditched and Swing went for "lightweight" components).
> They often introduce whole new situations that need to be handled by the
> developer specifically for that app (e.g. a toolbar that is still showing
> after all the active windows are closed). The difference between platforms
> like mobile and desktop are significant.
> 
> 3. Provide platform specific APIs that expose certain features (e.g. system
> toolbar manipulation and control) and throw exceptions if those features
> are not supported on that platform. This requires the developer to do a lot
> more work, and write custom if-then-else code to support each type of
> platform (if they want to take advantage of that platform's special
> features). It is a fairly safe/honest approach however, unlike the magic
> solution, which does stuff without you really getting involved in the
> process. The specific API approach keeps the control of the
> application/features in the hands of the application developer who is
> really the only person who knows exactly what their app should do on a Mac
> vs Windows vs mobile.
> 
> For me I prefer option 3 as I'd rather do a little more work and make sure
> things work properly and consistently. I'm pretty sure I might be an odd
> one out in this case (I also dislike CSS selectore for the same general
> problems with consistency and predictability - and most people love this
> stuff), so the leaning will most likely be towards option 2. In that case,
> I think it's just important in these cases to make sure the magic really
> does work and work well.
> 
> 
> Looking forward to hearing other points of view on all these topics!

I think it depends. For some things that can be done consistently across platforms (or, well enough for most uses) I'm in favor of an API that can span all platforms. However there will always be some stuff that simply isn't the same everywhere, and we want to allow people the maximum native integration they can. So for example I see nothing wrong with having a javafx.ext.macosx package which had Mac specific APIs for doing Mac specific stuff. I wouldn't want to have to resort to that for doing a menu bar. But perhaps there would be a MacApplication subclass of Application which would have extended APIs for doing mac specific menu bar stuff. I'm just making it up here as I go along, but that was the general idea.

Richard