I use several APIs to write GUIs including SWT, Swing, Netbeans RCP and Eclipse RCP. I have a lot of experience with Swing, I know it has some design flaws, it is sometimes cumbersome to use and its hardware accelerated pipelines don't allow to get consistent speedups. According to some (unconfirmed) rumors, some source code is simply copied from AWT to JavaFX which will make it difficult to run under Android. I assume PureSwing required a lot of work, I don't feel able to rewrite Swing alone even though there is already an hardware accelerated implementation of Graphics2D based on JOGL (GLG2D). What would you modify in Swing if you had to rewrite it?

Personally, I would try to make the following changes:- support touch screens and multi-touch (in the same way NEWT does)- support gamepads- add a build-in charting API (like JavaFX)- better separate the general behavior of components from the look and feel- emulate native look and feels instead of relying on native features- use OpenGL hardware acceleration to draw every components- try to remove some non uniform or incoherent behaviors (for example it is difficult to modify the font used in the edition zone of a combo box, there are other examples...)- let the developer set the event dispatching thread to ease the interoperability with SWT, JavaFX, etc...- support CSS (like JavaFX)- expose some parts of the API that handle the data manipulated by the GPU to ease the integration in existing 3D engines (Ardor3D, JMonkeyEngine, 3DzzD, Xith3D, Java3D, ...)- modify PhoneME Advanced For Android to support a larger subset of JavaSE instead of relying only on a very poor subset of J2ME

Yes, that was a massive arse, not being able pass in Lists to Swing models.

I must have been one of the few people who actually liked Swing. It was/is by far and away the best cross-platform UI and codebase I've used. Just look how wretched Qt is. Using the GIMP makes me want to hurt random people afterwards.

As far as I'm concerned JavaFX is the new Swing and has all the bells and wistles you'd want from a modern GUI toolkit. No need to rewrite it again It actually reminds me a lot of how Android works there.

Why is that an issue? Personally I'd prefer it if it relies more on native features, rather than emulating a native look&feel.That said, I sort of like the Metal look&feel. It's clean, fast, and easily 'themeable' (dunno if that's actually English ).But what I miss in Metal is that it doesn't follow certain native features, like system font sizes (which is an issue since displays are quickly getting more pixels/inch which can make Swing GUIs difficult to read because they don't follow the OS there).

As far as I'm concerned JavaFX is the new Swing and has all the bells and wistles you'd want from a modern GUI toolkit. No need to rewrite it again

JavaFX doesn't have a date picker of any type, and it doesn't have a masked/formatted text field like swing. That's only two fields that I've wanted since I started using it 2 days ago. I'm sure there are many more!

As far as I'm concerned JavaFX is the new Swing and has all the bells and wistles you'd want from a modern GUI toolkit. No need to rewrite it again

JavaFX doesn't have a date picker of any type, and it doesn't have a masked/formatted text field like swing. That's only two fields that I've wanted since I started using it 2 days ago. I'm sure there are many more!

As far as I'm concerned JavaFX is the new Swing and has all the bells and wistles you'd want from a modern GUI toolkit. No need to rewrite it again

JavaFX doesn't have a date picker of any type, and it doesn't have a masked/formatted text field like swing. That's only two fields that I've wanted since I started using it 2 days ago. I'm sure there are many more!

JavaFx is not ready. Thats why it still didnt replace swing.Yet.

But it will. Oracle said so.

Anyway, javafx > swing > AWT

True, some things are missing, but imho it's got the basics right.In the meantime there are very usable 3rd party date-pickers and masked text fields (the latter is really easy to implement anyway).

As far as I'm concerned JavaFX is the new Swing and has all the bells and wistles you'd want from a modern GUI toolkit. No need to rewrite it again It actually reminds me a lot of how Android works there.

In my humble opinion, JavaFX has some really cool features but it has some design flaws that were already in Swing and Java3D.

At first, you cannot set the event dispatching thread. This is very problematic when you want to create fully realtime 2D GUIs mixing JavaFX and other UI APIs. When I start working on an existing software at work, I cannot suggest to rewrite everything from scratch. The use of bridges allows to use several UI APIs together but when you can't use the same thread to update the GUIs, one of the UI APIs have to be prioritized which means that the other ones will receive the events a bit later (this is not a problem in some cases). I already had this problem when mixing SWT and Swing.

Secondly, JavaFX high-performance hardware accelerated graphics pipeline has several backends like Java2D and Java3D <= 1.5 which are painful to maintain and produce inconsistent results across platforms. I have found a way to disable the Direct3D pipeline in Prism but if the OpenGL pipeline is badly maintained under Windows, it will be problematic when you must use OpenGL (you want to avoid conflicts at driver level).

Thirdly, as a consequence, it is very difficult to implement an efficient interoperability between JavaFX and existing OpenGL bindings.

Fourthly, according to some unconfirmed rumors, some parts of AWT are used in JavaFX. Anyway, Oracle has no plan to support JavaFX on mobiles whereas there are more and more opportunities under Android (and Dalvik VM is still significantly worse than JavaSE).

Why is that an issue? Personally I'd prefer it if it relies more on native features, rather than emulating a native look&feel.That said, I sort of like the Metal look&feel. It's clean, fast, and easily 'themeable' (dunno if that's actually English ).But what I miss in Metal is that it doesn't follow certain native features, like system font sizes (which is an issue since displays are quickly getting more pixels/inch which can make Swing GUIs difficult to read because they don't follow the OS there).

It complicates the port, it is harder to maintain (just look at all required efforts to keep 2 OpenGL bindings working under Mac OS X), if the support of native look and feels impacts the UI manager too deeply then you can get "standard" components behaving very differently under some platforms , it means that you cannot test the native look and feel of a given platform on a platform that doesn't natively support it. Sorry but I don't want to buy a Mac.

Yes, that was a massive arse, not being able pass in Lists to Swing models.

I must have been one of the few people who actually liked Swing. It was/is by far and away the best cross-platform UI and codebase I've used. Just look how wretched Qt is. Using the GIMP makes me want to hurt random people afterwards.

Cas

Actually of all the GUI toolkits, I like Swing the most. Did plenty of tools with it, works like a charm and the custom painting isn't too bad to handle.

Its just really dated nowadays, although the specialized look & feels can also solve that. I was always very partial to substance for example.

Swing is an impressive API and nice apps can be written with it, but it is overly complex. Some complexity is necessary and some of the stuff Swing can do, especially the level of customization for some widgets, is very impressive. The rest is a bit of a mess. Swing has layer upon layer (eg, AWT), tracing events, layout, etc is hell. Part of the problem is that Sun refuses to do spring cleaning. Everything is always backwards compatible and over many years you end up with layers and layers of cruft. Things must be refactored and made nice so everything makes sense and fits together well, otherwise it doesn't.

Swing has poor layout support (just like almost every UI toolkit out there). For proper layout you need a scheme for validation/invalidation. Swing has this, but it is a bit weird. You also need *good* layout managers. Swing comes with a handful of crap layout managers (again, just like almost every UI toolkit out there, eg Android UI) that A) only do the job for simple demo apps, or 2) are too freaking complicated to actually be used (see GroupLayout). Yes, a proper layout manager can be written for Swing (eg tablelayout works with Swing) but the percentage of Swing users that will use a 3rd party layout is tiny, most struggle with GridBagLayout or hobble themselves with GridLayout and friends. Same on Android, tablelayout works there too but UIs are built with the horrible Android layout managers (made worse only by the inclusion of XML to design UIs, but that is a separate rant).

Skinning a Swing UI is nearly impossible. There are almost no docs and it is crazy complicated. I could never figure it out.

So to answer your question, I would build scene2d. I want my UI toolkit lightweight, easy to understand, easy to trace through, and easy to skin. scene2d has its warts for desktop UIs, eg focus traversal is lacking, but they are not insurmountable.

I don't think CSS is a good idea. The complexity explodes. Too many crazy features like that and you quickly have a monolithic UI toolkit that is hard to use.

I didn't use Matisse and Scene Builder but once used the WindowBuilder. The provided window border became over some components in Ubuntu when tested. The window metrics are different across OS'es.

Sounds like you weren't calling Window.pack(). "WYSIWYG" layout tools tend to generate bad code (which plays very badly with revision control systems). That's why some of us would much rather have good layout managers which let us express what we want in code than rely on GUI editors.

GUI editors may have worked ok back in the early 90s but these days you absolutely need programmatic layout managers doing the work properly. Swing could have done with a few more common layout managers such as a "FormLayout" and tweaks to existing managers to make them more flexible or easier to use.

The general appearance stuff, and possibly animation stuff, would be great. Probably not the layout stuff though - swapping one bad thing for another! Still, we've just moved to using Compass / SASS for websites - using that on the above website was a joy compared to skinning the application itself!

To go back to your point about the NetBeans Platform, there is an interesting question there as to what happens with older, large-scale software if / when JavaFX takes centre stage. Migrating any such large code base will not be an easy task - though it is possible to integrate JavaFX components into Swing, that's hardly ideal. There have been a few interesting discussions about that on the platform mailing list.

I guess the key thing I'd look at doing if rewriting Swing would be to relook at the MVC aspects of it, and try and move as much as possible of the logic and model stuff outside of the UI toolkit entirely - make migration easier!!!

Everyone always complains about Layout managers in Swing. I have never had a problem getting it to do what I want. Is it more just the nesting required to get layouts to work that people don't like?

I complain about layouts under Android but not about Swing layouts which are ok for me. SWT layouts are less reliable, I wasted a few days because of a very buggy class handling constraints in the table layout.

The general appearance stuff, and possibly animation stuff, would be great. Probably not the layout stuff though - swapping one bad thing for another! Still, we've just moved to using Compass / SASS for websites - using that on the above website was a joy compared to skinning the application itself!

To go back to your point about the NetBeans Platform, there is an interesting question there as to what happens with older, large-scale software if / when JavaFX takes centre stage. Migrating any such large code base will not be an easy task - though it is possible to integrate JavaFX components into Swing, that's hardly ideal. There have been a few interesting discussions about that on the platform mailing list.

I guess the key thing I'd look at doing if rewriting Swing would be to relook at the MVC aspects of it, and try and move as much as possible of the logic and model stuff outside of the UI toolkit entirely - make migration easier!!!

This is a very important aspect. I would like to know how Netbeans Platform will evolve on the long term. Yes the view and the controller seem tightly bound in Swing. Netbeans Platform follows the design pattern DCI, it's a bit better than M on one side and VC on the other side.

Everyone always complains about Layout managers in Swing. I have never had a problem getting it to do what I want. Is it more just the nesting required to get layouts to work that people don't like?

It's the lack of flexibility. Often a grid is fine, but rarely do you want the cells the same size. Often you need a few extra pixels between something and this flexibility just isn't possible without using GridBagLayout, which has the usability of a turd. That video is so spot on, it's sad. GroupLayout is a nightmare, it isn't how people naturally think about layouts. FormLayout I'm not very familiar with, but using tables is the WTG IMHO, so they got that right. It uses a DSL for column and row constraints which is unintuitive and moves layout data away from where the widget is added to the layout, which hurts readability a lot. Also specifying column and row for each widget is awkward. MigLayout is a complicated beast that IMO tries to do too much and also has an unintuitive DSL. A DSL also leads to string concatenation when you have dynamic values, which is nasty.

Back to the point, most Swing layouts suck, even 3rd party ones. I'm not saying you can't build apps with them, I'm just saying it is unpleasant. Not to single out Swing, the same is true for most (all?) UI toolkits. Obviously I'm biased by my baby, tablelayout but once you learn the constraints (there are only 7, only about 3 of which you most often need) then laying out almost anything via code is easy, and the resulting code is easy to read. You can quickly build a mental model of the layout so you know how to modify it to get what you want.

There is one other 3rd party Swing layout that I think is neat, DesignGridLayout. It uses canonical grids for layout. The example code mostly just adds widgets to the layout and that is all. It's amazing what it can do without any constraints! The downside is that you can't tweak it to meet your needs, you are SOL if you need a little extra space or in fact anything that is not a canonical grid. I prefer a single layout manager that is easy to use and enables most layouts.

Swing does a pretty good job at emulating the platform's look and feel, except for JFileChooser. Especially on OSX. In my own apps, I'm now relying on FileDialog for OSX since it isn't complete crap.

Swing is not a bad framework given its scope and complexity. Java2D is also great for what it aims to do -- cross-platform and consistent raster graphics for UI and simple visual apps. But neither platform is very "future proof" in today's world of mobile phones and tablets, hardware rendering, Google Glass, Oculus Rifts, Leap Motions, and so forth.

P.S. I recently used Nate's TableLayout in a Swing app, it's way nicer to work with than the default layouts.

@princec, nah, SpringLayout sucks too. You can't look at the code and get a meaningful idea of what the layout is going to look like. IMHO, people don't think about layout by what edge of something is attached to something else's edge. They think about tables. Table tables tables, all the way down.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org