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

[CaptainJester]

@doos

The amount of sizes you have to set to make stuff work. Setting size doesn’t work, setting defaultSize doesn’t work, setting preferred size doesn’t work, then you have to create a random dimension object to set another size. Seems like I’m always setting everything to get it to work.

Unless you are sub-classing a swing component you should not be trying to set the size. If you are sub-classing then you should over-ride getPreferedSize() to get the correct size you need.

Repaint is awkward. I end up with every class having a local reference to the repaint thread and it is annoying. My custom list has altered? Well I need to repaint everything then, oh, I cant.

You don’t need to repaint everywhere. Repaint cascades down the hierarchy. Just repaint from the top most point you need to. If you have multiple custom components that need repainting then you might want to think about only having one.

Some of the behaviour is twisted. It says in the javadoc that it works when you do X, but in reality it only works when you have a bunch of random prerequisites which it didn’t tell you about. Did you remember to call method doRandomStuff(XYZManager x) AFTER you have created the object? Well it doesn’t work. Should have been in the constructor then, shouldn’t it?

Would need a specific example to comment.

The amount of inherited fields and methods gets in the way sometimes. I know it inherited them from Component, but I don’t care about them and I cant find the method I am actually interested in. I would prefer swingObject hasa Component.

Agreed.

Some children are possible only from a JFrame, but not in nested objects. So you want a filedialog window to appear when you click a button in your panel? Well, you can’t.

If you are opening a dialog that needs a JFrame you can either pass null or create a dialog builder class that contains static methods but you set it up in the JFrame and pass a reference to the JFrame object.

Is swing JFrame the one where you cant convert easily to an Applet?

You should never put anything directly on a JFrame other than menus. If you want to make your application applet friendly you should build your app from a JPanel down and then you can use that JPanel in either a JFrame or JApplet.

[CaptainJester]

@gouessej

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

If you are thinking of starting a project like this I would be interested.

If you want cross compatability with Android, libgdx might be an option.

[sproingie]

I’d make it support Java 8 idioms and nothing earlier. Starting with closures: I’d still use listeners, but I’d allow most of them to be replaced by closures, including splitting up bulky interfaces into single-method listeners as appropriate. Next jdk8 trick I’d pull would be to replace most uses of inheritance with interfaces, putting appropriate default behaviors on the interface.

I’d make the MVC design completely optional throughout. All components would be shamelessly stateful, and you should be able to easily derive models from components and new components from models without having to declare clunky model classes that only work with Swing. Long as we’re going with interfaces, you should be able to have abstract component types anyway, same reason you can talk about an ArrayList or a LinkedList as an abstract List without needing to carry around an extra object to do it.

I’d give GridBagLayout a pair of concrete shoes and a swim.

[Grunnt]

For me, JavaFX sounds really nice on paper, but I somehow never managed to make anything useful with it. Unlike Swing, which I find quite easy to use.

The pre-Java 7 requirement to installing a framework to be able to use JavaFX was a big barrier to adoption IMHO, especially considering the crapware-pushing installers associated with Java. Embedding JavaFX runtimes was complicated, compiling a tiny tool with Excelsior JET turns into a complicated mess using JavaFX.

Swing, being part of the standard Java distribution for ages now, does not give me this trouble. The only real problem I had with Swing was layout. MigLayout soved this partially. I must say SpringLayout sounds cool as well, I’ll look into it next time I have to make a Java tool.

So for me, if you want to make a better Swing, please make it a simple library without needing any binaries, frameworks or dependencies ;D And make layout easy. Other than that Swing is just fine as far as I’m concerned.

[gimbal]

@sproingie

I’d make it support Java 8 idioms and nothing earlier. Starting with closures: I’d still use listeners, but I’d allow most of them to be replaced by closures, including splitting up bulky interfaces into single-method listeners as appropriate. Next jdk8 trick I’d pull would be to replace most uses of inheritance with interfaces, putting appropriate default behaviors on the interface.

I’d make the MVC design completely optional throughout. All components would be shamelessly stateful, and you should be able to easily derive models from components and new components from models without having to declare clunky model classes that only work with Swing. Long as we’re going with interfaces, you should be able to have abstract component types anyway, same reason you can talk about an ArrayList or a LinkedList as an abstract List without needing to carry around an extra object to do it.

I’d give GridBagLayout a pair of concrete shoes and a swim.

… 100% agree. I think I’ve used a shared model between two components exactly once in a Swing application, and that was because I wanted to toy around with shared models, not because it was particularly beneficial.

[Nate]

[quote=“princec,post:37,topic:43185”]

@Nate

Well… actually all of our nifty resizable UIs in our games are designed exactly like this, giving us resolution independent layout, too. Once you’ve worked with it for a while it’s hard to do layouts any other way.

Tables also give you resolution independent layout, but in a way that is easy to visualize. Except for the simplest layouts, you can’t look at a bunch of SpringLayout constraints and know what the layout will be, you’ll need to run it and see what happens. When you run it and it doesn’t look like you want, you’ll have to go back and stare at the code. With tables you can turn on table, cell, and/or widget debug borders and easily see what is going on.

In TableLayout resolution independence is done by saying which columns and/or rows fill the remaining space. This can be weighted, but it is rare to need that. Widgets provide a pref size and the table lays them out at that size. If there isn’t room, then they get sized smaller, down to their min size. Most layouts don’t hardcode widget sizes, the table adjusts based on the size the widget wants to be. If running on a different sized screen or with different sized widgets, the layout still works.

[Zhon]

<<---- BorderLayout master race

[gouessej]

@BoBear2681

(and not being “native” when bindings for native toolkits, like SWT, were the cool thing).

It depends on your customers, some people don’t expect a native “look and feel”. SWT applications are difficult to maintain, there are different layout problems even on different versions of Windows (XP, Vista, 7), for example when you put exactly 2 icons into a vertical toolbar, sometimes the icons are set horizontally under some versions of Windows :s

I have already seen a real commercial JavaFX Web application deployed once, the switch from a separate version to install with Java 1.7 to the integrated version caused a lot of troubles (it still doesn’t work on some machines and we don’t know why). The memory footprint is very high compared to Swing and even the API seems not very mature, there are already several methods who do exactly the same thing (close() and hide())… Pisces software rendering engine (AWT-free) is known to use a lot of memory (because of the (ab)use of Arrays.copyOf()). For me, JavaFX is not ready for prime time, especially with no OpenGL backend for Windows (in Oracle Java, not in OpenJFX).

Netbeans Platform is really cool but there is a real lack of documentation. Of course, I can look at the source code. The problem is that I understand the design of this API mostly by reading its source code and I have already seen numerous examples that simply don’t take advantage of the life cycle of objects to do the things correctly.

[BoBear2681]

@gouessej

@BoBear2681

(and not being “native” when bindings for native toolkits, like SWT, were the cool thing).

It depends on your customers, some people don’t expect a native “look and feel”.

Aye, to a degree, that’s what I was alluding to. A few years ago, native looking (desktop) apps was what everybody wanted to build. Nowadays, we’ve done a 180 and everybody wants unique looking apps. Or maybe it just seems that way because so much stuff is being built as webapps these days, and it’s so much easier for designers to get creative with CSS than it is with a programmatic styling API like Swing LookAndFeels.

[ClickerMonkey]

@Nate

TableLayout looks pretty nifty, do you mind if I integrate it into my game engine? (my game engine isn’t public just yet)

TableLayout does look several magnitudes better than anything in Swing…

[Nate]

@ClickerMonkey, yes by all means, use it! See one of the TableLayout backends for how to extend it for a UI toolkit. Eg, here is the scene2d Toolkit impl:
https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/scenes/scene2d/ui/TableToolkit.java
And the TableLayout impl:
https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/scenes/scene2d/ui/TableLayout.java
That is all you need to extend it. You can integrate it into your engine however you like, it can be a layout manager not in the scene, or a scene object that lays out children. In scene2d Table is the latter:

libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/scenes/scene2d/ui/Table.java

It delegates a ton of methods for convenience. Also it might help to see how layout invalidation works in scene2d:
https://code.google.com/p/libgdx/wiki/scene2dui#Layout
This way layout doesn’t happen every frame, it only happens when something changes size that might affect the layout.