Still don't understand how we went from this to modern GUI toolkits.
It looks and works so intuitively.
replies(14):
Like others have said, it works well until you need to support different screen sizes, layouts, animations, touch interaction, etc.
If it were a very simple window or dialog that always showed the same amount of information, you would disable maximize, resize, and position it absolutely. This allowed you to add "reactivity" incrementally instead of forcing everything to be reactive up front.
I considered this table stakes for any thoughtfully-written piece of software. There were of course exceptions for fixed dialogs that weren't interacted with for long and comfortably fit any small screen.
The page or two of hand-crafted code tended to be at least as readable, and often moreso, than the declarative HTML and CSS gooblygook that's common today. And in practice as a user I found the result tended to be more useful than many of the so-called "responsive" websites I see today - which tend to hide content in annoying ways, ignore opportunities to compact whitespace, plaster the screen with outsized ads, etc. - to the point I sometimes request the "desktop" site in my mobile browser in an effort to chase down a more humane experience.
It was when monitors started changing sizes. Everyone used to have 800 x 600. Then the market exploded.
And different monitor resolutions appeared and became divergent way before the iPhone came out.
There was a period in desktop applications where some apps were absolutely positioned and didn't support anything apart from the 800 x 600 layout. You'd get this huge gutter on the right and bottom of the application window.
It was fairly brief, as changing forms from absolute positioning to relative positioning in VB6 was pretty easy.
It turned out that focusing on a splashy and idiosyncratic brand not only excited prospective new users but inhibited them from going elsewhere since it made transitions more awkward and frustrating. That made more money, more easily, than focusing on user efficiency and feature distinctions as had been the trend before then.
The technology then trailed behind this fashion and invested its complexity budget in style customizability, animations and type rendering enhancements, etc and gave up on trying to encourage a standard design language that publishers and users could both build fluency in.
It was frankly, a shock to see how easy this model was and then see the monstrosity that came to pass for HTML and CSS positioning. Baffling.
Everything you just listed was easy in VB 6 IMHO (well, touch wasn't a thing exactly).
In fact, it's better now because it's easier to line things up and change their properties etc, but the interface is the same. It has literally not changed in 25 years.
Here, I booted VS2022 and made this app in under 60 seconds:
> This is fairly similar to how Interface Builder in Xcode works for macOS and iOS apps.
Totally agree with your second point and I wish Microsoft would have addressed that. Maybe they have. The last time I messed with their stuff I was writing XAML.
Anyone know if they brought RAD back?
Edit: apparently they had/have layout managers.
The other was that the alternative to VB for GUI creation was wrestling with class libraries, at a point when OOP was utterly baffling to many casual programmers like myself. Just the bare minimum "hello world" kind of app on either Windows or a Mac was page after page of instructions.
I suspect that over the span of subsequent decades, demands on high quality GUIs have increased -- as mentioned by others. But also, the programming skills needed to build a small GUI using code have become more mainstream, maybe because the languages have gradually made it easier.
Today, for the quality of GUIs that I need, I'm actually happier to just code them, and let (in my case) Tkinter lay them out in an acceptable default arrangement. My victims, er, users haven't asked for anything better.
Did it? I know .NET WinForms does with Control.Anchor, but that is VB.NET, not VB6.
It’s been many years but I don’t recall any method for that in VB6. As someone else noted you could handle the resize handler and move things around yourself.
I also recently found out my mfc tools are per monitor high dpi aware without any interference from my side.
Which was okay back in the day. Everyone had low display resolutions, so simply scaling a window's controls when resizing was okay. No need for responsive layout and even too fancy layouts, I guess. But what we got later with anchor in WinForms, layout panels in WinForms or WPF, layout managers in Swing, and CSS layout die help reduce the math you'd have to do yourself, especially for more complex layouts or even when the layouts change due to different requirements.
Then there's Gambas on Linux (though tbat requires WSL2 or Cygwin to work on Windows). Gambas does almost everything VB6 does using an obviously copued GUI and language.
Modern toolkits just do a lot of stuff that older toolkits didn't. Some times at the expense of not being as quick to get off the ground as VB was.
The original winforms implementation in the early 2000's was pretty close to VB in terms of efficiency but its warts were numerous, e.g. the DPI used in the designer view (when writing the code) affected what happens when you run it, and so on.
We were just amazed things existed at all.
Now, people shame people using WYSIWYG or VSCode or whatever else makes the life of people easier, other than top hard-core users.
And that's why even placing a centred text in the middle of a web page requires to know a whole stack of tech, and no step is you actually placing it there directly.
Interface Builder was a lot more like VB and Delphi in the past, but around the time of iOS 3, Apple completely broke the UI programming metaphor in it. It used to be all drag and drop (with quirks) but actions were like event handlers and outlets like events. Before it was "code first" you could do it all in the UI. I used it quite a bit before XCode existed (XCode used to be ProjectBuilder, even on like Jaguar/Panther IIRC) and it was very close to the version of the same on OpenStep.
Xaml designer - well, the designer is not really a thing because Xaml is usually not created as an absolute layout. There was a version of the Xaml designer early on that would attempt to build a UI that looked absolute, but it did a lot of horrible Xaml markup in the background and made maintaining the UI way harder than it should have been. We (Xaml users) all migrated to using it as pure markup and mos of us now use hot-reload over a designer.
https://platform.uno/blog/uno-platform-studio-featuring-hot-...
Which can make each app fit the appearance of the given desktop.
Old guis also had more accssibility features.
The only thing modern ones have going for them is animation and visual customization.
That said, the VB6 drag-and-drop interface was always flawed. 90% of the time you want to lay out controls in some kind of nest of layouts with clearly-defined resize and reflow behavior instead of "drag and drop wherever and YOLO if something changes size". A good GUI framework would nudge you towards that instead of free-form drag-and-drop wherever.
Which is a pity; I was watching a client do some crud work in a webapp.
Web - 1 form per page:
Click "back". Copy some text. Click forward. Paste it. Repeat for 3 different fields. Click submit.
Native apps (VB/Delphi/etc) used to be:
Open both forms. Copy and paste from one to the other. Open another one on the side to lookup some information, etc.
Webapps, even moreso with MPA, force a wizard-style interface - you only go forward through the form. This is not how people used to work; they would frequently have multiple forms in the same app open at the same time.
With SPA and html "windows" made out of movable divs you can probably support multiple forms open at the same time, but who does that?
Other point is noted. But let’s compare the alternative:
1. Fiddle with a config file for each app for a week. Distro includes this in dark mode set. 2. Each app writes custom code to listen for and adapt to dark mode events.
My taste did not; I experienced this shift as the triumph of designer ego over humble usability, and a little bit of my youthful love for computing died in the process.
I guess I can see your point. I started with IB on OPENSTEP, then onto macOS in the 10.1 days. But even back then, I still think the feel wasn't quite the same, from my subjective viewpoint.
I keep having these strong urges of using Windows again and creating WinForms apps. But then I go and use Windows for a day and the lack of polish is so jarring. But gosh, Microsoft development was almost always fun.
But with CSS you can get this kind of look, and then go even further, adding rounding and textures and all the things that are natural and obvious extensions on a high res screen.
macOS introduced system-wide dark mode a few years ago, but app developers had to recompile and opt into it. This was done so that they could adjust their artwork and overridden colors to it. Windows 10 added dark mode, but only for "modern"/UWP apps. Classic Win32 apps need to implement their own dark mode with custom themes/controls (like Explorer does).