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.

Now admittedly I've used MigLayout for years, and wouldn't claim it's perfect, but having looked at TableLayout I don't understand what it offers that MigLayout doesn't, apart from the added features / bulk which is useful in a small minority of cases. The important thing for me is the separation of layout from component hierarchy, which I find to be one of the most annoying things about the built in layout managers.

You don't have to use the DSL with Mig btw - there's also the API which is somewhat similar to your API in use - no issues with string concatenation of dynamic values.

GridBagLayout is a bit cumbersome to use, but other than that I don't see any game-breaking issues with it. It could have been more convenient to use, but it works for me.

As for UI designer tools, I just hate them with passion and I generally don't trust developers that rely on them.In my opinion a good UI designer doesn't exist. They either generate horrible code, are too limited to do anything good with it, are a pain to use, or just completely screw up things halfway. Usually it does all of that.

Usually GUIs designed with them end up as horrid non-resizable windows with no layout management at all (the sort of thing that's still all too common within the Windows OS) and don't quite behave as they should.I've tried to use them a long time ago when I started out with Java and when Swing seemed to be a bit intimidating as a newbie. Using a GUI designer such as in JBuilder, NetBeans or some Eclipse plug-in seemed a good idea. Boy was I wrong. Especially JBuilder and NetBeans seemed to try to emulate RAD tools like Delphi but using java/swing, but it just never worked.You actually save a lot of time *not* using them and to just actually learn what you're doing, and use Swing the way it was intended: Just code it.I also never use Android's GUI designer, because it still suffers from the exact same issues.

I think JavaFX and Android UI are sort of nice. They steer you towards a clear separation between views and business logic, and they're very flexible.I prefer JavaFX there, because it's just easier. Android has a too many gotchas for my taste and I tend not to do everything with XML, but generally it's still quite good. I wish that we didn't have to put up with issues related to 'ConvertView' and such, and there's quite a learning curve in other things as well.

Sometimes my least favourite part of the platform. It's definitely one of those areas that shows the problem of evolving a complex API in a large project.

Don't know if you've seen this blog post on how I created the custom sliders within the property sheet? No idea if it's any use to you - I'm just happy I got it to work!

This is the part of the API I use the most. I was forced to use the reflection to get the first Node.Property object when selecting multiple nodes in the connect() method, using PropertyModel.getValue() just throws a DifferentValuesException in this case. Yes I saw this post

As for UI designer tools, I just hate them with passion and I generally don't trust developers that rely on them.In my opinion a good UI designer doesn't exist. They either generate horrible code, are too limited to do anything good with it, are a pain to use, or just completely screw up things halfway. Usually it does all of that.

In my humble opinion, you can't use Matisse a bit, you can get some quite good code if and only if you use this tool as much as possible. If you mix generated code with hand written code, you get the cons of both approaches. I know some people who don't want to learn how to use layouts and who complain when I create GUIs without Matisse :s

Now admittedly I've used MigLayout for years, and wouldn't claim it's perfect, but having looked at TableLayout I don't understand what it offers that MigLayout doesn't, apart from the added features / bulk which is useful in a small minority of cases.

TableLayout offers simplicity while still offering most of the functionality. I see you're right about not having to use the DSL, that is good. I shouldn't have been so hard on MigLayout, it is on the right track for what I want from a general purpose UI layout (tables), it's just that it also comes with a boatload of extraneous stuff. IMO when building software there's a narrow path to walk, you need to know which features to put in but also which not to put in.

For games, you usually just want a 2D or 3D surface to render to such as OpenGL.

IMO, JavaFX is much better than Swing or even WPF/Silverlight on the .NET side. However, none of the above are good fit for games. For productivity apps like CAD, Photoshop, programming IDEs, JavaFX would make sense.

I'd be interested in hearing legitimate gripes about JavaFX. Its seems to be a complete improvement over Swing.

gouessej raises some points. To paraphrase:

1) Interop with legacy AWT/SWT/Swing code is weak. I've never tried to mix Swing/JavaFX in the same project, but I'll take your word it's sub-optimal. But this doesn't really impact new projects.2) JavaFX problems with different back ends. I am skeptical. I've run JavaFX apps on many platforms and this wasn't a problem.3) JavaFX interop with existing OpenGL bindings. Are you talking about having an OpenGL rendering frame inside of a JavaFX app? I imagine CAD and 3D modeling would want to do that. Those serious apps don't want to use the JavaFX 3D scene graph; they do want JavaFX basic widget GUI functionality, but they want to use their own 3D engines.4) JavaFX doesn't work with Android/iOS/mobile. Same with Swing, the Oracle JDK, and pretty much everything Oracle. Oracle is supposedly working on this.

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

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.

2) JavaFX problems with different back ends. I am skeptical. I've run JavaFX apps on many platforms and this wasn't a problem.

It seems to work in desktop environments. JavaME generally supports a subset of AWT (see the Foundation Profile) but Android doesn't support AWT; if JavaFX relies on AWT, it will be a problem. Have you ever used JavaFX on a smartphone? The other problem was the (not really smooth) transition from the separate install of JavaFX to the inclusion of JavaFX in the JRE. Anyway, I won't use JavaFX until it is fully supported in OpenJDK.

3) JavaFX interop with existing OpenGL bindings. Are you talking about having an OpenGL rendering frame inside of a JavaFX app? I imagine CAD and 3D modeling would want to do that. Those serious apps don't want to use the JavaFX 3D scene graph; they do want JavaFX basic widget GUI functionality, but they want to use their own 3D engines.

I'm talking both about using OpenGL rendering inside a JavaFX application and using JavaFX widgets inside an existing OpenGL application. We can't use scenegraphs based on OpenGL if JavaFX forces the use of Direct3D under Windows. I just hope the flag of Prism will work but I fear that it will be tricky to use. It is only an hint, it indicates the order in which backends are picked up if several ones are available. If there is no OpenGL backend under Windows, you are forced to use the backend relying on Java2D, look at "prism.order". If the Java2D backend is less used and less maintained than the Direct3D backend, then OpenGL programmers will have some more troubles

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.

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.

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?

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.

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.

I'm yet another idiot who loves Swing. Once you get past the steep learning curve, it's both very powerful and configurable. I think it just got a bad rap for looking like crap for so long (and not being "native" when bindings for native toolkits, like SWT, were the cool thing).

I never touch GridBagLayout. You can do everything you need with the other built-in layouts, and a fair amount of nesting. It is often easier to use a 3rd-party LayoutManager though.

Besides what's already mentioned here, maybe that application framework JSR that never got off the ground, based on NetBeans RCP I believe. It would help remove a lot of boilerplate from Swing applications of any appreciable size.

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.

Typically, if you find yourself calling set*Size() on any components, "you're doing it wrong." Properly-used LayoutManagers size everything properly for you 99.9% of the time.

Quote

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.

I'm not sure I follow? You can create and show FileDialog (or JFileChooser?) from any JButton anywhere in your UI...

Quote

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

Either one would just be a container for your UI. If you want to write an application that can run in both a window and an applet, typically you'd add all your components to a JRootPane. JRootPane is basically all the content in your GUI application. Then you can shove your JRootPane containing your application content into either a JFrame or a JApplet.

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.

Quote

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.

Quote

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.

Quote

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.

Quote

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.

Quote

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.

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.

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 And make layout easy. Other than that Swing is just fine as far as I'm concerned.

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.

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

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.

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

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

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