Don’t tell anyone, but I still think we’ve been terrible at UIs since VB6 and Hypercard.
We mostly gave up on 2D grids as device resolutions evolved. We made HTML, then made HTML5 as if everything was a blog or newspaper with a navigation bar, semantically (and you still have to learn that the nav contains a bulleted list?)
Unfortunately, it became a 3-hour or 3-year or 30-year process for someone to learn “how do I add a button at the bottom-right of my app?!”
Windows Forms with C# still works excellently. Sure, Microsoft has deprecated it a bunch of times trying to push a new UI paradigm every year, but good old WinForms will never die.
The language is much better and the editor has more modern controls. Win32 calls are available relatively easily and the whole program runs quite a bit faster than VB6.
It's a shame that this is so often overlooked. At some point everyone seemed to have switched to WPF and that's when .NET cross platform GUIs seem to have died. There's a new tool out there right now but that doesn't work on Linux so I can't say I really care when WinForms will work perfectly on any operating system Mono has ever been ported to.
Yep. I cut my teeth making custom .ocx components. That teenager was part of your dll hell!
VB.net is pretty good, but at that point I just used C#. I go back and make C# guis every now and then with winforms. It always makes me think “how is everything else including QT and WPF and CSS worse decades later?” ;)
And how about that experiment with Electron? That ultimately ended up with me typing `atom foo.py` a few times a month and then being sad (50% of the time because it takes forever to load, the other 50% because it died like 3 years ago and isn’t installed).
I'm still using it although I'm not sure it's a great idea anchoring yourself in the past like that. Also the high dpi stuff has been improving but isn't really very good.
For all the criticism Apple gets on backwards compatibility I think they have a much better story than Microsoft when it comes to UI frameworks.
I completely agree. I've played with VB6 a few times recently and it feels so fast and natural to make a UI compared to modern frameworks.
A bit part of it feels like a dedication to highly polished developer tooling. A strong GUI editor that works with (mostly) zero configuration is a big feature of VB6 to me.
I don't speak for everyone, but in the end what bothered me of VB6 was that it was simply very slow. But nothing compares with the joy of loading some obscure .dll and finding out you now had some neat and fully functional component ready to lay out in your app.
Heyyyy ;) Computers were slow. Java applets were slowest. These days I think QT is slow.
It’s not, but with the decadal upgrades in hardware… there should be things that load instantly. Everywhere!
(Deep breath on my end. Ok.) It’s like how games went from a few kilobytes at most, to megabytes disk or dialup… to blue CDs, to 4.7gb, to blu-ray, to 0.5 TB downloads, to second mortgages.
And most of them suck anyway! We will always max out our tech, even if it doesn’t get us much. I mean… we bought that hardware for reasons.
> A strong GUI editor that works with (mostly) zero configuration is a big feature of VB6 to me.
IMO even Delphi 1 had a better GUI form designer. The "Align" property that many controls had, including containers, allowed for visually creating resizable layouts easily since that placed a control to one of the left, right, top and bottom edges of its parent (multiple controls could be stacked) or at the "client" area which basically covered the remaining area. VB had a similar property but IIRC only the picture control supported it (the picture control was also used as a container) and could only place controls to the edges but not the client area. This meant that pretty much any non-trivial UI that needed a resizable window had custom code for the resizing event to handle that instead of being done visually.
Delphi later added a simple "anchor" property to allow custom placed controls to be resized too (the default setting was to anchor to the left and top edge which behaved like before anchors were introduced, but e.g. anchoring a control to the right edge in addition to the left caused the control to be resized horizontally when its parent was resized and anchoring it only on the right caused it instead to move horizontally).
Nowadays Lazarus provides a more advanced anchoring system (e.g. you can have a label control be aligned vertically at the middle of a combo box control and the combo box's left edge to be aligned with the label's right edge with a margin of 5 pixels) which is set up using a visual editor (no code needed) but it also provides the Delphi-like anchors and align properties as well as a bunch of other properties that can be edited visually, like min/max sizes, child control placement, etc all of which make it IMO by far the best WYSIWYG form designer for desktop GUIs (though the anchor editor's own UX could be improved).
And this is why I absolutely refuse to do the whole HTML and Co. method of doing GUI's to this day. (XAML etc). I use tools like ETO instead where possible, where I define my UI in code, and it's built to the native UI toolkit whereever relevant. At no point am I writing fucking XML (why does anyone think this is a good idea?!) for a UI. I'm saying I want a title bar with these elements, directly in code. It's fantastic, and should be how it happened in the first place.
You may like my project, once I get around to open sourcing it.
I feel, of the three ways of designing guis, the most explored is the declarative way, and there seems to be an assumption by everyone that this is the best way...
But, there is absolutely no data that I could find that supports this view.
I made a small js library to make it easier to quickly write the widgets and layout of widgets in code only.
So fa I'm preferring my code components to react components.
> “how do I add a button at the bottom-right of my app?!”
Whenever I work with a WYSIWYG GUI designer I ask myself a different set of questions instead:
Is this button really in the bottom right, or does it just happen to look that way at the current window size?
Is the spacing on all sides actually equal, or are the pixel coordinates just close enough that I can't see the error?
If I click the button to find out, will I accidentally move it and introduce the error I was trying to detect? (And the version control system can't do much to help with blobs of generated layout code/data.)
> Is this button really in the bottom right, or does it just happen to look that way at the current window size?
To be fair, that would mean you're not using a WYSIWYG GUI designer. With VB6, you could resize the window, in the editor, and watch the elements move around.
Sure, but you have to manipulate the window to find out, instead of knowing that it's in the bottom right because that's what you specified.
And now your carefully set window size has changed, just because you were trying to find out the layout parameters of the button. So you have to go and poke at the properties of the window, if you can remember what size it was supposed to have, And hope you don't accidentally change anything else in the process, because "git diff" isn't going to be much use.
Well, maybe it's just me. I prefer writing a specification (e.g. source code), which can be reviewed and diffed, and then compiling/executing it.
Your points don't match how the VB6 editor presented the settings or behaved. You seem to think it was some pure WYSIWYG interface, which it wasn't. You could parametrically (in the properties window) and programmatically do whatever you wanted.
> instead of knowing that it's in the bottom right because that's what you specified.
You did specify the anchors, in the properties window. If you wanted, you could easily verify you had everything correct by resizing the window.
> And now your carefully set window size has changed
If you thought that exact size was important, then you would just have it set to that special size at startup, by setting the "width" and "height" property of the window, or whatever other thing.
> because "git diff" isn't going to be much use.
> I prefer writing a specification (e.g. source code)
You could define the whole interface programmatically, if you wanted, and many did. Sometimes, there was some hybrid, where you would draw up the main window, then throw programatic stuff in a frame/whatever container, because sometimes that makes sense.
The purpose of all of this was to make things easy and take less time. In some, going the programmatic route is a great way to increase billable hours, sometimes it a great way to decrease them. Sticking with one method over the other doesn't make sense to me, because that would be an emotional decision rather than a practical/efficiency one, right tool for the right GUI/window/dialog box, and all.
We mostly gave up on 2D grids as device resolutions evolved. We made HTML, then made HTML5 as if everything was a blog or newspaper with a navigation bar, semantically (and you still have to learn that the nav contains a bulleted list?)
Unfortunately, it became a 3-hour or 3-year or 30-year process for someone to learn “how do I add a button at the bottom-right of my app?!”