Crinus

I wasn't talking about such a thing. I was talking about being able to create a "plaf" theme using a visual editor or at least some rules in CSS or similar script that applies to the entire Swing application (like Swing's own plafs do) and doesn't require creating subclasses. This has nothing to do with having a designer or not and it is orthogonal to it (you can give the tool/rules/whatever to a designer if you want).

I was talking about themes, not UI design. Think GTK themes (though not their implementation), not where buttons in a form will go.

This doesn't fix the issue of Swing theming being hard. The fix would be to make it much easier, preferably with a visual editor.

That sounds to me like saying nobody will ever make a new C++ compiler because C++ is hard and good compilers are hard - before Clang.

The problem with Swing theming is that you need to create a ton of classes "just" for theming your application. I did that years ago myself, but really Swing should have something like those libraries released years (>10) ago that had a bunch of premade themes as well as WYSIWYG editors for them.

There used to be many libraries (most of them were awful, half of them tried to mimic circa 2002 Mac OS X Aqua) so i do not remember any names, though i remember trying one with a visual editor that i gave to a designer at the place i worked at. We didn't ended up using it though because of the price.

I remember >10 years ago there used to be some "plaf" libraries that provided very easy themeing abilities for Swing that even came with a WYSIWYG tool to create themes. It is a shame something like that never became part of Swing itself and instead you have to create tons of classes just for a theme.

> in the past licensing wasn't really compatible with these kinds of scenarios, and you'd often have to purchase the software 5 times.

That is only because of greed. During the 80s and 90s, Borland for example had a "no-nonsense license agreement" that told you to treat the software as a book: make as many copies as you want, have as many users as you want and even resell it as long as - like a book - only one person at a time is using it.

They did change it at some point in the 2000s, probably around the time when they stopped selling Delphi for $99 as the cheapest option, introduced online DRM and prices skyrocketed to the thousands.

> As far as I know, the only way to fix this situation is by building tools so much better than the free tools that the absurdity of refusing to pay for them is overwhelming, and expectations shift.

This of course will only work for a little while until someone who has more time than money (or is a big company that wants to commoditize the tool) will build a command-line version of it on Linux. Weird UX and the need for a spaghetti of shell scripts to integrate with vim/emacs/vscode/sublime/ed will soon follow with an Eclipse addon that nobody will use a bit later. After a macOS port, assuming these are still a thing, Apple may create a nice looking UI and integrate it with Xcode or someone like Panic may create a good front end and sell it for ~$99.

Most people will keep using Windows, think Visual Studio has the best debugger and everyone will be happy.

Those that learn about the "overwhelmingly better approach" will consider the free one the best one and its spaghetti of shell scripts approach the obvious best approach, because they wont have any real deep experience with the paid tools (either the original one or the macOS shiny wrapper - which will be considered as unnecessary by most anyway) to properly judge.

Note that with the edit and continue appearing in VB he meant the immediate window in VB1, not the C++ feature. Also this didn't really appear with VB1, it most likely "appeared" with the first BASIC Bill Gates wrote (as far as Microsoft is concerned, BASIC had it before MS) as any number-based BASIC was able to both run and edit code at the same time and this was evolved to QuickBASIC/QBASIC's "immediate" pane at the bottom where you could run functions as soon as defined them in the editor and modify the program's code and state by pausing it and then this was passed on to VB1 though a dedicated window that remained there until VB6.

I do not like compositing though, at least not the way it is implemented in pretty much every current desktop environment (including Windows) where the composition is synced to the monitor refresh rate, meaning that it will always be at least ~8ms late on average and that is assuming everything else is synchronized - but this is not the case as applications draw their output offscreen to a surface that is picked up by the compositor (the mechanism of which is irrelevant, the application might just render to a compositor provided resource or the compositor might copy a VRAM surface or it may transfer bytes from the system RAM, it doesn't matter much in what i'm describing) which happens asynchronously and then notify the compositor that the window contents have changed which is again picked by compositor asynchronously. This introduces several frames of delay between the application drawing something and it appearing on your monitor. It is not a big problem when you are passively watching something, like a movie or an animation, but when that "something" that is drawn is an immediate reaction to an action you just did (like resizing a window with your mouse) you can "feel" that delay.

With non-composited window systems (which nowadays is pretty much only Win7 with DWM disabled and pure X11/Xorg) all that overhead goes away since applications draw directly to the video memory that is to be presented to the monitor (the GPU might do some minor composition itself but that is irrelevant as there aren't any delays involved).

Compositing would work if all composition was done on the GPU using dedicated hardware (similar to how the GPU already performs composition for the mouse cursor and an overlay that is often used for HUD-like controls like volume control, but those are not general purpose features that can be used for desktop composition) and applications could draw directly to the video surfaces that would be composited pretty much the same way a non-composited desktop can draw directly to the video memory (this would introduce artifacts like tearing but this is something that could be handled separately and to some - like me - tearing is perfectly acceptable for pretty much all interactive actions).

I am not aware of any GPU or window system that does compositing like this though.

This is just a longer worded version of Rewrite It In Rust :-P

The last time there was a real UI and UX consistency was with Windows 2000 (or ME, if you want to stay on the consumer side). With Windows XP Microsoft introduced themeable controls but instead of making them available to all applications, they used an opt-in mechanism (based on special EXE resources or manifest files) so even nowadays unless you use that mechanism you get the Win2K era of controls.

Even then, with Windows 7 most things were consistent and if you really cared about consistency even with non-themed apps you could always switch to Windows Classic theme (which i always did, not so much because of consistency but also because i just like that theme :-P).

Since Windows 8 with the introduction of Metro/UWP/WinUI/WinWhateverNext consistency was thrown out of the Window, without even trying to pretend otherwise (it isn't a coincidence that the UI guidelines for desktop applications in Microsoft's site still use the Win7 theme).

And games, medical, research, etc.

In my previous job i was working on game tools with wxWidgets, in my current job i am working on game tools with Qt. In between i got an offer (which i rejected since i am interested in games) for a Qt tool to be used for (IIRC) DNA research (or something like that, i'd just be doing the UI not the actual logic).

I am not talking about technical matters here (and FWIW Stadia is based on Linux), i am talking about control. Games that i stream from my own PC to my own handheld (or whatever) are still under my control, so that is perfectly fine. Games that i - wont, but just for the sake of argument - stream from Stadia are under Google's control which is not fine.

Proprietary platform dependence isn't much of an issue when you can hack around that platform. A win32 game using directx on my own PC is way more preferable than a Linux game using Vulkan on someone else's cloud server.