FxDock does work on Linux

[andy-goryachev]

FxDock https://github.com/andy-goryachev/FxDock does work on Linux. Please correct Readme.md

Thanks! -a

[kasemir]

I did not intend to disparage FxDock. I removed it from the list so your lib is not mentioned in the context of Linux-related issues.

For what it's worth, I just downloaded the latest FxDock, compiled, and this is what I get when I try to drag a dock from one window to the next:

In this example I tried to drag the lower right tab. The drag starts, but then freezes. This is on Red Hat Enterprise Linux Workstation release 7.4, Java 1.8.0_121, gnome desktop. For some reason all the docking libraries that create a new window to drag around as the visual feedback fail in a way, I believe because the gnome desktop interferes with the mouse events.

With Java 9, FxDock doesn't build:

$ ant
..
compile:
    [javac] Compiling 325 source files to .../git/FxDock/build/classes
    [javac] .../git/FxDock/src/goryachev/fx/edit/FxHacksJava8.java:5: error: cannot find symbol
    [javac] import com.sun.javafx.scene.text.HitInfo;
    [javac]                                 ^
    [javac]   symbol:   class HitInfo
    [javac]   location: package com.sun.javafx.scene.text
    [javac] .../git/FxDock/src/goryachev/fx/edit/FxHacksJava8.java:46: error: cannot find symbol
    [javac]         HitInfo h = getTextLayout(t).getHitInfo((float)x, (float)y);
    [javac]         ^
    [javac]   symbol:   class HitInfo
    [javac]   location: class FxHacksJava8
    [javac] ...git/FxDock/src/goryachev/fx/edit/FxHacksJava8.java:54: error: cannot find symbol
    [javac]         HitInfo h = getTextLayout(t).getHitInfo((float)x, (float)y);
    [javac]         ^
    [javac]   symbol:   class HitInfo
    [javac]   location: class FxHacksJava8
    [javac] Note: Some input files use or override a deprecated API.
    [javac] Note: Recompile with -Xlint:deprecation for details.
    [javac] Note: Some input files use unchecked or unsafe operations.
    [javac] Note: Recompile with -Xlint:unchecked for details.
    [javac] 3 errors

[kasemir]

docking libraries that create a new window to drag around as the visual feedback fail in a way

Specifically applied to FxDock, it creates a Stage dragWindow when drag is started. With our combination of Linux and X desktop, the events that used to go to the drag handler now seem to go to the newly created stage, so the original drag is hung.

[kasemir]

I assume that on your Linux setup, my ant demo1 works OK? On mine, ant demo1 has the same problem as FxDock, only ant demo2 works.

The downside to not using a dragWindow is that there's little visual feedback when you drag a tab around. Tried updating the Cursor to reflect what's dragged, but then noticed that some users who use ssh -X to connect to Linux from certain Windows-based X tools are limited to small cursors, so you cannot set the cursor to be an image of the dragged tab.

[andy-goryachev]

Thank you for extensive writeup and investigation. I'll create an issue in the project and try to find a workaround.

[andy-goryachev]

now in JBS: https://bugs.openjdk.org/browse/JDK-8292922

[kasemir]

Hi Andy, Two years later and you're still looking into this, that's persistent! Thanks for reporting it up to the JDK level.

[andy-goryachev]

That's four years ;-) Since I am a part of the javaFX team, I want this thing fixed.

[kasemir]

4, you're right. Good to have somebody who can count look into this ;-) Thanks again!

[andy-goryachev]

thank me when it's fixed ;-) may I ask you - are you still using javafx in your work or did you switch to something else?

[kasemir]

Very much so: https://github.com/ControlSystemStudio/phoebus, https://controlssoftware.sns.ornl.gov/css_phoebus/, https://controlssoftware.sns.ornl.gov/training/2022_USPAS/

It's a pity that desktop graphics are currently somewhat out of fashion. It's all about web GUIs, and they sure are nice for the end user. But for our use case of control systems, we're on a local network, so cloud-based web servers aren't practical. We do have some read-only web based info displays, but while web GUIs are nice to use when they're well implemented, doing that is a lot of work. Desktop tools in a type-checking language like Java are somewhat easier to develop, IMHO, so we still do a lot of that. Eventually, I'm hoping for either a comeback of desktop graphics, or compiled and type checked development environments for web tools.

[andy-goryachev]

https://controlssoftware.sns.ornl.gov/css_phoebus/ - looks very nice!

I too, lament the apparent decline of high performace / high quality desktop graphics and propagation of js. Just try to maintain or refactor a complex piece of js code when all the original developers have left and there is no string type system to help you. It's a pity: SpaceX and JWST now run js - scary! I think a big part of it might be relatively high barrier for entry in platforms like javafx or swing.

if you were to name 3 (or any other number) of missing features in javafx platform as a whole, what would that be?

[kasemir]

I'm generally happy with it. The Separation of code, fxml and css can be a hindrance in what I'm doing, so personally prefer just code, but have to deal with css because some widgets don't have a "setBackground" type API, must revert to "setStyle" and then try to locate and then understand the modena.css.

My main concern is stability and availability for Linux, Mac and Windows.

One feature that could be better is the Canvas or WritableImage support. For our plot-type widgets, having each axis be a scene graph of lines for the tick marks and labels for the axis labels etc. results in too large a scene graph overall and then slowdown. Instead of creating large scene graphs for each plot, we want to "draw" the plot as an image in background threads. Tried to draw an FX Canvas in background thread, but that just tends to queue up drawing requests. Best case, they are then performed when the Canvas is shown, on the UI thread, so UI thread is still doing the work. Worst case, the queue of to-be-executed drawing commands overflows.

The WritableImage allows preparing an image in a background thread, but the PixelWriter is very limited. It can really just set a pixel, not draw lines or text.

So in the end we create plots as background images using the AWT BufferedImage, where Graphics2D can draw lines and text etc., then convert the AWT image into an FX image and show it in a canvas... Means we also have to translate colors and fonts between AWT and FX to get the same look. Would be great if WritableImage was like AWT BufferedImage with a drawing API that's larger than the PixelWriter, usable off the UI thread to prepare images.

[andy-goryachev]

Oh yes, I too never even used fxml. It might be good for a simple case, but, generally speaking, it's fater and better to do everything in code. The XML part of FXML assumes some kind of visual builder - surely, noone is expected to maintain XML by hand, right?

As for css, I ended up generating a stylesheet - https://github.com/andy-goryachev/FxTextEditor/blob/master/src/goryachev/fx/CssLoader.java

I think in jfx17 they have added support for data: url so one does not need to register a url stream handler, but there is still no meaningful way to generate or modify css programmatically.

Generating (complex) plots in a background thread might be a problem - you do want to use accelerated FX graphics, so I suspect any background threads are out of question. You could try generating plots in pieces - but keep in mind that the actual rendering still happens in a different thread. One can try to do as much pre-processing in a background thread, but the actual rendering still needs to happen in the FX thread, as far as I know. I am talking about Canvas solution, of course, as the large scene graphs are going to be slow regardless.

Thank you so much for your feedback! No promises, but I hope to make some meaningful contribution to the platform, however small it might be.