What would you modify in Swing if you had to rewrite it?

General Discussions
#1

Hi

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
#2

Inconsistent - it’s a false friend.

The biggest design problem I had with Swing is its reliance on java.util.Vector and java.util.Hashtable rather than genericised List and Map.

#3

Where and how was it a problem? Can you elaborate please? Maybe in JTable and JList?

#4

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 :slight_smile:

#5

Otherwise… by Java 7, GPU acceleration was pretty good if you ask me. Some long-standing bugs could have done with dealing with. The lack of a pure Java HTML5+CSS3 component was its main downfall.

Cas :slight_smile:

#6

I’ll

– Set native look and feel as default
– Add more layouts and
– Integrated gui designer like .net platform

#7

Yes javax.swing.DefaultComboBoxModel takes a Vector in input, or an array but then you have to convert your list to an array (by using List.toArray()).

It makes sense if you don’t want to annoy the end user and if you want your application to look like native ones.

Why is it important for you?

I know a very little bit .NET. Aren’t you already happy with Matisse, WindowBuilder and Scene Builder?

#8

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 :slight_smile:
It actually reminds me a lot of how Android works there.

A bit annoying, but it’s a really minor issue imho. Those are just some default models where usually you’d implement your own models anyway.

#9

[quote]emulate native look and feels instead of relying on native features
[/quote]
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).

#10

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!

#11

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

But it will. Oracle said so.

Anyway, javafx > swing > AWT

#12

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).

#13

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).
[/quote]
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.

#14

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.

#15

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. :slight_smile: 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.

#16

I find layout managers in Android a lot more crappier than in Swing.

Netbeans Platform is a very good solution based on Swing but a lot easier. I noticed some nice stuffs nsigma made with it in PraxisLive ;D

Maybe supporting only a subset of CSS would be enough.

#17

I like MigLayout well than the default ones. So I’ll integrate it if I had rewritten swing.

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

#18

And one more

– I’ll add HTML 5 support for [icode]JEditorPane[/icode]'s [icode]HTMLEditorKit[/icode]

#19

I didn’t know that, thanks.

#20

[quote=“SHC,post:17,topic:43185”]
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.