In my imaginary company that I own where we all run linux laptops that are managed by puppet or something, I think we might make a strong case for building many internal tools in Swing.
The biggest hurdle I see nowadays to using Swing is all about distribution: both of the jvm and the program. Imo that's really where the web won - certainly not because of its dev productivity. So it's definitely a no-go for your actual software product.... but for internal tools where you have a lot more leverage over the environment, I think it looks extremely attractive.
Regarding JavaFX... Honestly, I really like it. I have a personal project that was originally in Swing and I ported it to JavaFX because HiDPI is in a lot better shape there (though I think Swing has since figured it out?). And it's a lot better in many ways. I love-love-love using SceneBuilder for designing the view layer and the Observable pattern, I think, yields a lot of nice QOL/verbosity-reducing things.
That said, I think it did have a slightly higher O() for frustration than Swing's O(1). And I think the community, as a whole, just understands it less (less prior art etc).
So if someone said "build a usable high-quality GUI asap or you die" to me, I'd go to Swing immediately.
Java Web Start (JNLP) worked great. It just worked. His customers loved him.
I've always wondered why something like desktop JNLP didn't happen.
JNLP did a good job of solving the app distribution/update problem, but required that you already had the JRE installed. Not too much different from assuming a browser is installed, but I found it much less likely that a user would take the initiative to install a JRE than a browser. They just don't understand what they are doing or why in the case of the language runtime.
That said, it did work very well, in my experience.
A jnlp app is a file format that defines how to launch a java executable over the internet. It defines the location where the executable is, and what version of java is required. Opening the jnlp to download and launching the app requires an installed JRE, or there is nothing to interpret the jnlp and go get the application.
There is, iirc, a utility that will wrap a jnlp file and go get a jre. I forget what it's called, but it makes jnlp apps more like an auto-updating standard app.
The benefit of the jnlp approach is if you can guarantee your users have java installed, then they don't need to install your app. Just click a link, then a java app self-downloads, installs and sets up a shortcut on the desktop. And it updates whenever they open it and a new version is detected.
Wasn’t that Marimba/Castanet?
A.) ...they never figured out a good/unobtrusive update process for the JVM itself.
B.)...Sun faltered when they picked up steam. (Remember when IBM threw 1 billion USD at writing Eclipse in Java?)
I hear Java GUI has supposedly gotten better, but all of the Java GUI apps I see look awful. For instance, try telling that to Ghidra and it's butt-ugly text that shows up super thin on my hidpi display. I like Ghidra, but for a graphical RE tool, Cutter is so much prettier with its QT interface. Of course, r2 is great and works from CLI.
No one in his right mind loves the UI of Jetbrains Apps and the Linux experience has always been a shitshow unless you were using Gnome or KDE. Because Swing does not implement the XWindows protocol properly. So yeah, a great team can still make a functional app with terrible GUI technology -- but there is a world of a difference to something that's really polished, fast and enjoyable to use.
VsCode and atom are simpler, but they just don't provide UI, for many setting you have to go to config files, and some functionality is missing outright.
Can you think of an IDE with better UX?
I like being able to configure just about everything in just a single config file, but still getting an additional escape hatch for overriding OS default keybindings I want to use.
Also, the menu bar in IntelliJ was reimplemented from scratch to make it work properly. The Swing menu bar would have been unusable with its broken handling of submenus.
I suppose preferences here are at least partially determined by how you think about software project management. Eclipse makes perfect sense to me, and has since the first day I used it. IntelliJ is obtuse and odd and ... wrong to me.
I don't think Swing's MVC strategy worked out. It was worth trying. But maybe 40%-50% of the framework could be safely removed.
Some kind of DSL would be nice. JavaFX ain't it. In my own noodling, Swing's UI component hierarchy needed to be refactored to be fully composable. By the time I created enough shims to make Swing truly composable, I wish I'd started from scratch. (I haven't done Swing work in ages, so maybe this happened.)
An event loop is the biggest thing missing from Swing and other UI toolkits of that era. Meaning all modifications are handled by the framework, no client code (or non event loop threads) can modify the UI. My bestie George Smith's Juipeter (?) took the Win32 API approach, preserving the Swing API and all dispatch was handled under the hood. This is kinda how a browser's event loop is implemented. I much prefer an exposed event loop and Command objects. (It's easier to stepwise debug. Every desktop app I've ever created also had Undo/Redo; so you're gonna do Command objects one way or another.) And then make the framework pretty with some kind of DSL over the top.
Sadly, though inspired, I think Swing's LookAndFeel plumbing proved unnecessary. Sun believed everyone who said it mattered. Maybe it did for a while. But the world moved on. I still have no firm opinions on how I'd make an app reskinnable. (I should probably look to see what Qt's doing these days.)
Edit: I didn't mention AWT/Swing layout managers. Just peeked at Google/JetBrains Compose. Meh. I like that it uses Kotlin; less syntactic vinegar than Java. Alas, Compose repeats the mistake of not separating out the layout code. After doing way too much layout code -- some Australians did a hysterical GridBagLayout rage meme video, back in the day -- The Correct Answer[tm] is custom layout managers. Still include some stock managers in the JDK. And make the layout hooks API easier to implement and debug.
Well, if they didn't bake LookAndFeel in from the start, all of the work would fall on the application developer to manage these things. Having had to look into doing this the way they chose is the best way, what most people have a problem with is the UI didn't look fully native on most platforms for a long time.
One is that if the look and feel of an app is native to the platform then it can lean on a design language that users of the platform assume, which makes it easier for those users to understand how to use the UI. Affordances look and act the way they expect, which reduces the time and effort it takes them to learn a UI.
Another reason to prefer it is that a UI that doesn't look native stands out as different. Noticeable differences are information. If something in a UI gets your attention, it should be because it's telling you something meaningful. Gratuitous differences from the platform's UI standard are not telling you anything meaningful, so they're just noise.
A third reason is that native platforms provide their native looks and feels through standard frameworks that also provide substantial whole-system features beyond just making things look alike. For example, Mac users can rely on a common set of keystrokes to do the same things across almost all applications (and the exceptions are badly behaved). UIs built without the platform frameworks must either recapitulate all of these platform-wide conventions or just ignore them. Commonly, they just ignore them, which means that conventions that users take for granted stop working in some apps for no good reason.
Also back then browser apps were a novelty instead of how most people interact with computers most of the time, and thus anything that wasn't using a native toolkit stood out pretty bad. A few apps like MP3 players used it for their advantage, but I remember those as being mostly a confusing mess.
More importantly, font rendering has improved incredibly and most rendering looks the same across toolkits in the same desktop environment. Back then some toolkits supported antialiasing, some did not, some had godawful rendering that looked like crap, some couldn't render certain symbols correctly, some didn't have good hinting for LCDs, etc.
The reality is that very slowly most UI paradigms have converged into a few well-established patterns (no more multiple-window apps, no more focus-follows-mouse, no more deep right-clicked context menus, etc). So now the styling differences are more apparent but most UIs are functionally the same nowadays. The same could not be said 15 years.
We have come a long way; despite the different looks, the feel is much more uniform, and there's a better understanding of what makes for good UIs.
As I write this, I'm frankly quite thankful that we have reached this state of good-enoughness. Spending hours looking into GTK themes and different fonts was fun, but in a frustrating way in which no exact font-icon-theme combination was entirely satisfactory.
Most consumer applications are now webapps or electron apps. From accounting software to music players, they are not native.
If someone botheres to make a desktop app, you either have proffeshionals tools or resource intensive applications like Adobe Photoshop, Blender3D, 3Dmax, IntelliJ IDE's and Games. None of them look native either!
Almost noone bothers to develop platform spesific apps, and native applications are dying. If we don't stop squabbling about native look and feel, we will get no native applications at all.
Well, unless you're talking open source tools and/or everythign within the sphere of desktop productivity . Then invariably your "consumer" desktop apps of choice are some mixture of GTK2/3, Qt, Swing, WxWidgets......
Granted, the different GUI libraries and applications using them tend to have _slight_ inconsistencies (GNOME 3 / GTK3 window titles versus everything else's window titles), but for the most part they're consistently themed, they render quickly, they behave the same way with the clipboard, mouse interactions, element focusing, keyboard shortcuts, accessibility functions......
So I have open right now LibreOffice Writer, Firefox, Evolution, many gnome-terminals, Transmission BT client, GNOME Files, GNOME Boxes... all of which look the same and there's no cognitive load spent switching between them, because they behave the same and look the same.
I can open up Inkscape and GIMP and Evince and KeePassXC and VLC and retain that experience.
Meanwhile, whilst still my IDE of choice, my PyCharm (so, JetBrains) IDE windows do whatever the hell they want (STOP STEALING FOCUS!!!), glitch out rendering, look completely different. And Spotify - gets all its points docked just for how it handles tabbing through UI elements. ("No, I don't want to tab through ALL of the Discover page, I want tab to cycle through the different UI elements, preferably not taking a painfully long time to reach "search".... Ugh fine, CONTRIBUTE TO MY CARPAL TUNNEL THEN!!!)
"Native" (as in, "consistent experience across the whole suite of desktop applications") toolkits still make it way easier for _developers_ to design applications consistent with the rest of the system.
Android and iOS UI toolkits serve same useful purpose. I tend to find that apps that are just a reactive web framework in a fullscreen frame are pretty painful to use. Like, wtf are you doing when I hit back!??? Why is this full screen splash form with two text boxes SCROLLING when I touch it???
tl;dr of my rant: Goddamn people stop trying to make your applications look the same on every device and let me use it how I like on MY device, for the same of a) my wrists and b) my attention deficit brain
There were also some really good ideas that I wish had caught on (I was a huge fan of focus-follows-mouse and I still use the X select-into-clipboard), but the general uniformity of UI patters nowadays is very much calming.
Main benefit to me is deflecting spurious input. All that Drive By Management.
Instead of explaining the history of ergonomics, the philosophy of ethnography, and our reams of data from usability testing, I'd just point at Apple's Human Interface Guidelines.
Like name dropping Aristotle in debate class.
More serious actors will try harder, lean in.
I guess what I'm alluding to is something like CSS for desktop apps. I tried to tweak stock L&F a few times (not my choice) and I mostly failed.
Back in the day, there was a guy, Sven?, that crafted amazing L&Fs. I dimly recall he had one that was easily customized.
JavaFX supports CSS styling.
I just spotted JavaFX Script. Huh. This is almost directionally correct. So of course it got killed.
If you're curious what The Correct Answer™ is, imagine VRML-97 reimplemented using JavaFX Script like syntax.
Its wiki has a link to the Curl (programming language). That syntax is also directionally correct. But is also missing most of VRML's semantics.
There's also a link to the F3 programming language, aka "form fits function". Great slogan. Alas. Looks like a misunderstanding of Conal Elliot's Fran functional reactive programming language.
Oh well.
Thanks for the tip. JavaFX's Script w/ CSS was about 1/2 the solution. Maybe someday someone will loop back and harvest the good bits.
[1] https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/...
and of course vt100 escape sequences for some reason.
They are all you have if you don't know about FLTK, QT, Juce, GTK, wxWidgets and many others.
That said, there should have been one, good, cross platform GUI toolking, and Qt, for various reasons, isn't it. The best we have is Electron...
It's also worth pointing out that creating a cross-platform API is better for new players than for entrenched ones.
No client complained about either of those. And at the end of the day you could always call a method to get the platform look and feel and it could look like Windows or Mac OS. I had a menu to change this in the app itself.
I never found the UI development hard. I was hand coding it in the beginning. I thought the Layouts were pretty straight forward (except grid bag which I never used). Eventually NetBeans had a decent UI designer and I used that.
I think the sloppy or slow UI's came from developers who never took advantage of the Observable / MVC aspects of the UI components.
(Flash had many, many drawbacks: proprietary, security, ... but it was really easy, to make something nice looking, that also run smooth - it was designed for that and later taken to higher level with flex)
When people don’t laugh at Electron applications, I don’t know what could be wrong with Swing. Nobody cares about native toolkits anymore (what is native toolkit for Windows or Linux?).
There is the difference. This post is for people who do care about the looks. (or do care, that their users care) Some users don't care, which is fine to serve them, what they want, but most actually do.
"When people don’t laugh at Electron applications, I don’t know what could be wrong with Swing"
People do not laugh at electron apps, because they use html which is designed for good looking. In other words, usually much better looking. It is just not performant, unless you use native modules etc.
And native toolkits are still a thing. Gtk for linux for example.
Personally I also care about the looks, but I prefer function over form, meaning I want a functioning app first and secondly it should look good. But I like to have both.
However, most people do a lot of work to make web sites and apps attractive. You can do that work with Swing or JavaFX too. I've done it before, it was fine, I ended up with a modern web-ish feel to the UI.
Things that cost me a line in CSS, like text-shadow, probably would require me to implement a shader libary in swing.
Not in JavaFX where such shaders are pre-canned and there's a CSS dialect too. I wrote my web-like app in JavaFX. It was no big deal.
You mean Qt?
If there were a complete Swing desktop environment, Swing apps would be native to that environment. But even Sun's Java Desktop System was based on GNOME.
One thing to keep in mind is that you want a functioning app first with less than great GUI but then you also want an app that is "skinnable" in other words it should be easy to replace the look and feel without having to touch the application code. CSS-stylesheets attempt to accomplish that.
I was writing UIs in Swing 10 years ago, and we managed fine even back then, but our target customer is technical people so maybe our definition of "looks good" is somewhat easier.
And even SWT was far from perfect. It is one of those thing you can immediately tell by its looks, SWT, Swing, Linux, Mac , Windows. While the looks has been vastly improved, it still remain mostly true today.
Yup, there is the difference. My target audience are common people, so I have to care more.
The people who care about "looks good" are managers and designers because they never actually have to use the damned thing.
IMO this is an extremely important idea and where I think the modern GUI went off the rails. I also, think it's gotten much worse with web applications.
I agree with the Raskins' that the fundamental issue with modern HCIs are applications. A common UI context in which to run commands would be more preferable in most use cases. I'm thinking of some mashup of the normal social media timeline with Emacs M-X functionality to run commands.
But given the choice, they prefer the better looking one. In consumer facing apps much more. Especially younger people, used to shiny websites/html point out quickly, how ugly something looks. And then not use it.
As far as I can tell, this is a narrative that only exists in the heads of people who never have to use the thing they are insisting "look good". Sales people, managers, developers, etc.
I will accept that I'm wrong when I either experience it in the real world for myself or see some actual evidence.
Well, here in the real world, (because of the need of Windows) I just recently started to use Notepad++ again. It really pains me to do so. The only way to tolerate it, is by removing all UI and only keeping the text. But even then some ugly, contrast breaking window pops up, when I use search etc.
So I will likely switch to sublime text (even though I only have to work on windows sometimes). Simply because of aesthetics I choose a solution nicer for my eyes, when I have the choice, which I do.
Case in point: people still use Windows, and I've never had anyone tell me it's because it looks good.
Unfortunately the bullshit gods usually have more influence than should be allowed. But making something 'look good' in a sprint demo where the CEO is present potentially releases a lot of pressure and gives the team more time to build something that works.
I tried to do the same few years ago, couldn't find a reliable way.
When I tell Swing to display a simple window with some simple widgets, it will
1. First display the window in some random place on the screen,
2. Then move it to the position I actually specified.
3. Draw all the widgets with a slightly wonky layout,
4. Then erase the widgets it just displayed and redraw them with the correct layout.
This happens in every Swing app I've ever used when opening a window, even IntelliJ. (The glitching window position is not always observable.)
But we are trying it, and opinions (internal to my company) are varied. Some people like it, but I don't. Because (a) it has missing functionality here and there (b) it still has a long road to go to become battle-hardened (c) I don't see any of the current supporters having deep enough pockets to fix (a) and (b)
So we're taking a mostly wait-and-see attitude.
But we have an existing deep and wide investment in Swing in our products, so our risk profile is probably somewhat different to yours.
As far as I'm aware, it was only pulled from the JVM into a separate dependency, as did several other components, in order to keep the JVM slim. Are you saying development on it stopped altogether?
There are however, a couple of small companies, and some individuals using it, and providing contributions.
Gluon also provides builds for LTS and latest here: https://gluonhq.com/products/javafx/
If you need 3d, we drop into OpenGL and use that (e.g. when integrating WorldWind).
Sometimes I feel bad about how easy it is to write desktop UIs in Java - the API is stable, nobody keeps changing it under me, I don't have to wonder what Microsoft is pushing this year, it is (mostly) easy to debug, has open source forms designers (Netbeans), etc, etc.