> On Mar 13, 2018, at 3:04 AM, <toni.ep...@eppleton.de> 
> <toni.ep...@eppleton.de> wrote:
> 
> Hi Wade,
> 
> I agree, desktop isn't going away. At DukeScript we're using HTML4J Apis 
> mainly for desktop applications. The Java Desktop Application is just using a 
> HTML5-Component ("browser") to render the view instead of a native or Java 
> rendering pipeline. 

How are events handled then? If you want to open a file as an example? Are you 
running the JVM as a separate service backend and using web services?

> 
> Since the separation of view and view logic is very clean the view technology 
> can be completely replaced. In some of our commercial projects we used 
> Controls4J to render the view, in others plain HTML and CSS. I've got working 
> prototypes that use native controls instead on iOS and Android. Even one that 
> renders to JavaFX that I sometimes use for debugging. 

That sounds pretty cool.

> 
> And unlike Swing or JavaFX browsers are evolving at great speed and getter 
> better day by day without any investment on our side. That's a great benefit 
> if you compare that to the sluggish development of Swing and JavaFX that 
> we've seen in the past years.  
> 

Perhaps, but I think one has to bind a product to a specific and embeddable 
browser for something like NB and NB RCP, or perhaps some custom Webkit. 
Relying on just anything seems like a lot to support at that level.

I figure if views themselves can be replaced, then technically we could have 
our own native views instead. We could do some things based on OpenGL or Vulkan 
https://www.khronos.org/vulkan/ <https://www.khronos.org/vulkan/> or stay 
low-level yet remain in Java with LWJGL https://www.lwjgl.org 
<https://www.lwjgl.org/>, and not have any browser limitations. Here’s an 
example of an OpenGL based UI library https://github.com/wjakob/nanogui 
<https://github.com/wjakob/nanogui>
> I think that the stuff that Sean does with the crippled JavaFX 3D API is 
> amazing, but think about what he could do with a really good 3D API, like the 
> many that exist for WebGL. 
> 

I’ll let him speak more to this, but per his talks he tried different browser 
based 3D APIs, and the performance wasn’t there yet. Personally, I have seen a 
lot of WebGL components get the sad face uh oh in Chrome, and not be that 
stable; this on good hardware.

Wade

Reply via email to