3 ms·

> Fleet relies on the Java AWT/Swing framework to get a window from an operating system, but it doesn’t use the Java platform for managing its GUI components be

> Fleet relies on the Java AWT/Swing framework to get a window from an operating system, but it doesn’t use the Java platform for managing its GUI components besides one JFrame and JPanel on top of it. This is a terrible decision that is going to bite them in the long run. Doing things this way makes it far, far more difficult to implement accessibility, and regulations on this are only going to get stricter. Implementing accessibility for a framework like that would involve three separate implementations for three separate platforms and the need to interface with D-Bus, COM and Objective C, from Java. I imagine that the latter two would be particularly difficult, considering how bad Java's FFI support is. It's not just calling methods either, you'd actually need to implement your own classes that conform to the relevant COM interfaces / Objective C protocols. There are libraries that can help with this[1], but I don't think they would work particularly well for something as complex as a code editor. [1] https://github.com/AccessKit/accesskit https://github.com/AccessKit/accesskit

gecko 3y ago
It's worth noting that Compose Multiplatform, which makes the same core decision, actually has a pretty solid accessibility story (https://github.com/JetBrains/compose-multiplatform/blob/master/tutorials/Accessibility/README.md https://github.com/JetBrains/compose-multiplatform/blob/mast...). It'd be nice if I didn't need the Java Access Bridge, but that doesn't seem like a major break for me.
thriftwy 3y ago
Swing is notorious for not relying on underlying graphical system controls and drawing everything from scratch, and they are actually reinventing Swing on top of Swing. IDEA actually ships its own Swing implementation for decades because the default one from Sun/Oracle is intolerably ugly-looking.
ptx 3y ago
> This is a terrible decision At first I thought you were objecting to the other part of the quoted sentence and saying that relying on AWT/Swing at all, even for creating windows, is a terrible decision. These libraries are not good at handling windows. Sometimes windows can be seen being created in the wrong place and then moved afterwards, after being displayed. Sometimes focus is somehow moved to the wrong window when switching quickly between windows. And as far as I can tell there is no way to set a maximum size for a window, even though the underlying platform supports it. Since Fleet has to bundle native libraries anyway, maybe it would be better to reimplement that part as well. That would also (in addition to being less broken) allow removing the whole java.desktop module from the bundled JRE, saving lots of space.

gecko 3y ago

It's worth noting that Compose Multiplatform, which makes the same core decision, actually has a pretty solid accessibility story (https://github.com/JetBrains/compose-multiplatform/blob/master/tutorials/Accessibility/README.md https://github.com/JetBrains/compose-multiplatform/blob/mast...). It'd be nice if I didn't need the Java Access Bridge, but that doesn't seem like a major break for me.

thriftwy 3y ago

Swing is notorious for not relying on underlying graphical system controls and drawing everything from scratch, and they are actually reinventing Swing on top of Swing. IDEA actually ships its own Swing implementation for decades because the default one from Sun/Oracle is intolerably ugly-looking.

ptx 3y ago

> This is a terrible decision At first I thought you were objecting to the other part of the quoted sentence and saying that relying on AWT/Swing at all, even for creating windows, is a terrible decision. These libraries are not good at handling windows. Sometimes windows can be seen being created in the wrong place and then moved afterwards, after being displayed. Sometimes focus is somehow moved to the wrong window when switching quickly between windows. And as far as I can tell there is no way to set a maximum size for a window, even though the underlying platform supports it. Since Fleet has to bundle native libraries anyway, maybe it would be better to reimplement that part as well. That would also (in addition to being less broken) allow removing the whole java.desktop module from the bundled JRE, saving lots of space.