Hacker News new | past | comments | ask | show | jobs | submit login

In WinForms, it's still called Anchor (it really did take a lot from VCL), but since enums are scoped in .NET, you have Anchor.Left, Anchor.Top etc.

WinForms also had Dock (Left, Right, Top, Bottom, or Fill) which basically forced the control against that edge of its parent, taking up full length and/or height accordingly in one dimension, and using the explicitly specified size in the other. With multiple controls with Dock, they'd gradually fill the available space in Z-index order, stacking up against each other; then whatever control had Dock=Fill, would fill the remaining space.

So yeah, resizable windows were common, and easy to deal with. The real problem is dynamically sized controls themselves, e.g due to DPI changes, or because the control contains dynamic content of unknown size. With those, anchors no longer work well, and you need some kind of box and grid layouts. Which are available - but it's kinda hard to edit them visually in a way that's more convenient than just writing the corresponding code or markup.

The closest I've seen to visually editing UI that can accommodate dynamically sized controls was actually in NetBeans, which had its own layout manager for Swing. That thing allowed you to anchor controls relative to other controls, not just to the parent container. Thus, as controls resized according to their context, other controls would get moved as needed:

https://netbeans.org/kb/docs/java/quickstart-gui.html

https://youtu.be/_ZW4ktG1DEE?t=129

Still, you needed to be very careful in the UI form editor, to make sure that controls are anchored against other controls in ways that make sense.

Fundamentally, I think the biggest problem with UI designers today is that they can't really be WYSIWYG, the way they used to be in the RAD era. The DPI of the user machine might be different, fonts might be different, on some platforms (Linux) themes can be different in ways that drastically affect dimensions etc.




> Fundamentally, I think the biggest problem with UI designers today is that they can't really be WYSIWYG, the way they used to be in the RAD era. The DPI of the user machine might be different, fonts might be different, on some platforms (Linux) themes can be different in ways that drastically affect dimensions etc.

WPF and UWP can deal with it perfectly fine.


Last time I checked the WPF designer, it used canvas by default - which allows you to put elements exactly where you want by simple drag and drop, like the old times in VB6 or Delphi; but then nothing actually reflows or resizes etc at runtime.

If you choose to use layouts, it can display them, but editing it with a mouse is no longer convenient. It's easier to just drop into XAML and hack on it there. On every project I worked on that used WPF (which is quite a few by now), nobody on the team actually used the UI designer, and everybody would switch the default mode for .xaml files in VS to open the markup directly, rather than the usual split view.


WPF designer default template is a Grid layout, so it must been a very long time ago.

As for devs preferring to type by hand, well their loss I guess.


Using anchors and docking was extremely intuitive and easy in WinForms, I miss these heavily. I'm trying to build an UI with Qt Designer right now and using layouts instead is quite a pain when building something sophisticated. Perhaps everything can be done with them but becoming fluent in their behavior and tweaking is going to take time.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: