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.
Cas 
Hey! Thanks for the mention - glad you like it. Incidentally, all new (and first) website went live last week - www.praxislive.org
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.
I just realize that your skills in Netbeans Platform are better than mine. I sometimes spend a lot of time in writing custom editors and custom in-place editors. I use a lot the property sheet.
Thank you, I will have to look at it.
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.
[quote]I find layout managers in Android a lot more crappier than in Swing.
[/quote]
Well, I have to admit that there are an awful lot of ‘gotchas’ in Android layouts. In Swing, these things are a lot more predictable and easy to use.
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.
As far as I can tell all Swing layout problems were solved by SpringLayout.
Cas
@davedes, awesome! 
@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.
scene2d ui should support CSS
Writing an HTML/CSS renderer is exceptionally difficult. Matthias’ efforts in TWL are pretty amazing!
For advanced effects it would be better to hook into Chromium or WebKit to do the rendering.
It does have one particular use (especially around here). Makes you wonder why they bothered adding GridBagConstraints though! ;D
Well, it’s not really intended for people to use, but for layout builders / WYSIWYG. It came out of Matisse in NetBeans, which is useful now and again, though I tend to prefer hand coding.
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.
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! ;D
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.
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
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
Haha, a use for GridBagLayout? Up is down, black is white…
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.
Swing, SWT, and JavaFX are all tools for writing component-centric rich/fat-client desktop apps with component GUIS: tables, buttons, menus, text fields, etc.
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:
[quote=“Nate,post:29,topic:43185”]
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.
Cas
It would make sense except if you can’t disable Direct3D whereas your code relies on OpenGL 
It works but in the case I talked about, it has the same limitation than when mixing any other GUI APIs using different threads for event dispatching.
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.
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
Oracle recently published a survey to check whether supporting mobile is important for the developers…
Edit.: ES2 backend is not shipped with JavaFX under Windows, you have to build it from source (OpenJFX).
Deep breath… ;D
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.
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.
I’m not sure I follow? You can create and show FileDialog (or JFileChooser?) from any JButton anywhere in your UI…
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.