> Again, "anything fancy" here includes something as simple as a localized dialog. In most commercial apps, this means pretty much everything would require "drawing it yourself".

My day job is to implement a commercial ERP system that has never been and probably will never be localized.

All software I use on a daily basis is English-only, even when localized versions to my native language exist, because:

(0) The translations are absolutely horrible. Who in their right mind would think that they are actually “helpful”?

(1) Even if the translations weren't horrible, the extra complexity simply isn't worth it. (Admittedly, my tolerance for system complexity is rather low compared to most other users.)

So, from my point of view, when you talk about localization, you might as well introduce yourself as a visitor from a parallel universe (where localization is presumably useful).

GUI toolkits moved on since the 1990's.

Go download NetBeans and create a Swing UI in Matisse. You'll find these issues aren't an issue. You can drag/drop and end up with a flexible, responsive layout that can handle things like strings changing length due to localisation. You can do the same with Scene Builder for JavaFX, although it's not as slick as Matisse. Or even Glade, if you're more a UNIX person. The latter two tools require you to understand box packing but allow for a relatively responsive layout.

The thing they don't do is let you totally change the layout depending on window size. But that's a fairly easy trick to pull off by just swapping out between different UI designs at runtime. There are widgets that can do this for you.

I know that full well. But one thing that you might note about these tools that you've listed, is that they're nowhere near as simple as the VB6 form designer, that was exalted in the comment that started this whole thread. They're more complicated, because they have to deal with dynamic layouts, and you are exposed to this overhead even in visual mode.

I guess technically you don't have to use dynamic layouts. All toolkits and designers I've seen do allow absolute positioning. It's just discouraged.

But yes, these days, people do expect windows to be always resizable and that does add some complexity.

Even Windows Forms has a layout manager with data binding, but devs have to explicit take advantage of it, there is no need for "drawing it yourself".

WinForms layout managers are a pain to work with in the designer, though. It wasn't written with them in mind - they only showed up in .NET 2.0 - and it shows. Dragging and dropping things doesn't often do what you want them to do, and sometimes things just disappear, and you have to dig them out from the control tree.

Data binding is better in that regard, but once you start doing complicated nested data bindings, it's rather tedious to do it in the designer (because you can't just bind to "A.B.C" - you have to set up a hierarchy of data sources).

Worse yet, you start hitting obscure bugs in the frameworks. Here's an example that I ran into in a real-world production WinForms app ages ago (side note: I wasn't an MSFT employee back then, so this was an external bug report): https://connect.microsoft.com/VisualStudio/feedback/details/...

Having said all that, the aforementioned app was written entirely in WinForms, using designer for all dialogs (of which it had several dozen - we used embedded controls heavily as well), with dynamic layouts and data binding throughout. And it did ship successfully. So it wasn't all that bad. Still, not the kind of experience I'd want to repeat, when I can have WPF and hand-written XAML.