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.
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).
> 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.
Yeah, nah. I sympathize with your point of view, but implementing Pernosco requires some serious science. If you try building a database of all memory and register changes in a naive way, it isn't going to work at all for nontrivial programs. Of course it could be cloned, but you would need a very good team and a lot of work.
Also either you start with rr as a base, in which case you need people with deep rr knowledge, and I know their names, or you build or buy your own record and replay framework --- more time and money.
It's no longer likely at all, but some years ago my workplace nearly open sourced a serious tool. That would have been big news, with the sudden availability of source for a tool that does rr-like stuff.
Some other company could do it. Remember that we've gotten Navigator (now Firefox), Blender, OpenSolaris, OpenOffice, and the .net stuff. Governments can surprise us as well; the USA did that with Ghidra.
I'm not expecting it anytime soon, but surprises happen.
That's a possibility, but I don't know of any closed-source tool that does what Pernosco does. Tetrane is the closest I know of, but they aren't as scalable as Pernosco (they don't need to be).
Certainly possible that someone has a secret tool that's as good or better. However, I expect the secret tools in this space are all focused on so-called 'security research', i.e. more like Tetrane and targeted at adversaries of the software under test, rather than its developers, which leads to a somewhat different feature set.
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.
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).
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).
On one hand it looks neat. This is something i expected browsers to be able to do since i noticed that Mozilla (pre-Firefox) implemented <blink> (or <marquee>?) in JavaScript.
On the other hand it looks like it'll become much harder for JavaScript-less environments to extract data from web-pages as now an article on a news site could be something like <news-article id="23848923"> and the JavaScript side will do the rest.
But being able to do something like <my-fancy-button caption="Go To Google" target="http://google.com/"> that in the background creates all the canvases and such needed will be neat.
>On the other hand it looks like it'll become much harder for JavaScript-less environments to extract data from web-pages as now an article on a news site could be something like <news-article id="23848923"> and the JavaScript side will do the rest.
This is already the case on a lot of sites, just not standardized. With the standard you could sandbox the javascript or maybe implement specific parsing for the most common web components.
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.