I still can’t comprehend that VB6 had time travel debugging 20 years ago, and we still don’t have that with most other IDEs.
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?!”
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.
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.
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.
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).
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.
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.
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.)
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.
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.
> 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.