←back to thread

377 points porterde | 9 comments | | HN request time: 0.679s | source | bottom
Show context
wiseowise ◴[] No.42142078[source]
Still don't understand how we went from this to modern GUI toolkits.

It looks and works so intuitively.

replies(14): >>42142147 #>>42142252 #>>42142509 #>>42142582 #>>42142873 #>>42143270 #>>42143473 #>>42145120 #>>42145467 #>>42146571 #>>42147144 #>>42147616 #>>42148647 #>>42155384 #
1. Onavo ◴[] No.42142147[source]
The answer is simple, mobile and relative layouts. GUI builders are easy when you can just use absolute positioning for everything (see Retool and the dozens of Retool clones). They become insanely complex when you can't.
replies(5): >>42142262 #>>42142267 #>>42142329 #>>42142436 #>>42145326 #
2. ok123456 ◴[] No.42142262[source]
Windows Forms didn't use absolute positioning for everything. You could anchor things relatively to other controls or components. You would test how things behave when you maximize and resize windows, similar to how Devtools tests reactive designs now.

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.

replies(1): >>42143422 #
3. wiseowise ◴[] No.42142267[source]
I don’t buy it. Android has amazing Constraint/Motion layout that adapts on screen size. Instead of improving XML tooling they’ve decided to follow latest fad and created Compose.
replies(1): >>42145331 #
4. rkagerer ◴[] No.42142329[source]
I did extensive work in Visual Basic 6. Nearly all of the GUI's I created had resizeable windows that scaled gracefully. It was really straightforward to hook the Resize event.

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.

5. mattmanser ◴[] No.42142436[source]
Just want to add to what other people are saying, not only did VB6 support relative positioning, but the history of responsive sizing in applications wasn't because of mobiles.

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.

replies(1): >>42143410 #
6. epcoa ◴[] No.42143410[source]
> Just want to add to what other people are saying, not only did VB6 support relative positioning

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.

7. epcoa ◴[] No.42143422[source]
> You could anchor things relatively to other controls or components.

I don’t believe this was a feature that came out of the box in VB6. There is Control.Anchor in WinForms that is post VB6.

8. pjmlp ◴[] No.42145326[source]
Layout managers are supported for decades now.
9. pjmlp ◴[] No.42145331[source]
Thank the Kotlin crowd at Mountain View.