This is kind of a Mac topic, kind of desktop. Based on the screenshots in https://tracker.xojo.com/xojoinc/xojo/-/issues/79422 we are going to have a hell of a time handling control sizes and spacing. We now have different metrics on different macOS versions, as well as Windows and Linux. Just using the same 20px buttons, 22px fields, and 12px spacing isn’t going to cut it anymore.
This isn’t a new problem though. I use control subclasses that increase their height on Windows and Linux, and move up by half the delta so they stay centered. But this cuts into the spacing. It’s only a few pixels, but it’s still wrong.
I really don’t know how this gets properly solved. Auto layout is probably the closest we’ve come to a solution, but I recall it not being very popular, while being hard to use and hard for Xojo to maintain.
Geoff and I toyed with the idea of the layout editor having a mode switch that would use constants behind the scenes for each control’s size and position, so that each platform could have its own layout. There’s plenty of problems with this idea too.
I don’t have any better ideas though, short of writing a bunch of code to lay out our views properly. That definitely wouldn’t be pleasant either.
I hated AutoLayout when I first started working with it. Now I’m a fan. There are some issues with the system that I have to fight with from time-to-time, but I think it’s worth it now. Seems to me that adding AutoLayout to Desktop (maybe Web) would be the best way to handle these platform disparities going forward.
How about a layout editor (possibly distinct from the current one, or a new editing mode) where you can only place controls on a grid that is enforced by the IDE? Not a grid like grid paper, because that would be too rigid, but a dynamic grid of sizing and spacing that isn’t tied to any OS’s particular values. You’d end up with an abstract layout of controls that have certain specific heights and widths and spaces between them - with some of them, like multi-line edit fields and list boxes being marked as flexible so they can be enlarged or shrunk as needed.
The IDE then internally produces a window layout for each target platform, resizing the controls and nudging them around so that all the statically-sized controls can be made the correct size for that platform.
I think this is a reasonable solution for simple windows, where the exact positioning of the elements isn’t as important as looking correct for each platform.
For more complex layouts… you’d want a mechanism to create relationships between control edges, to let the system knows that resizing one control necessitates adjusting this edge on this control over here. It might have to be defined in code; I’m not sure you could easily cover all the possibilities using a straightforward layout editor.
You can kind of do that now with GraffitiLayout and the similar solution from Bjorn, by locking sizes and adapting distance between controls based on window/container size, but something more is needed here. I never thought I would say this years ago, but AutoLayout is really the solution.
Not that I’m aware of. It hadn’t been a popular proposition, as you mentioned. If you want to create one then I’ll sign on. Otherwise I’ll try to open one when I get in tonight.
I did a webinar last summer with examples of how this framework worked, but if you look for examples of Anchors with autolayout, I find that they work much better than the raw constraints.
Although this is a MacOS subject I’d like to point out that Windows UI uses controls that are 34px high & that is also going to have an impact on cross platform layouts.
We need to support RTL languages and that requires flipping the layout, With constraints it’s a lot easier. Greg’s ConstraintKit is a great start. I testing early versions and it sure helped with RTL and other issues. I just couldn’t get it to change the size of a window based on the constraints though. I’ve not checked it for a while so that could be fixed by now.
That may be true but there is alot more complexity currently. We need something that is easier to implement, something more clear, and without speed bumps.
The typical stack of controls with labels to the left was an issue. I wished for all labels to be as small as possible (intrinsic) but for the controls to be offset by the longest of them. This sort of thing:
Row 1 Label Control 1
Other label Control 2
Row 3 label Control 3
The controls need to line up with the longest label setting the width. I tried all labels intrinsic and equal width, right aligned. Which is contradictory I’m sure but you get the point. I think I sent you an example back in the day. The window width is due to some languages being much longer should push the window wider, others narrower.
Would help with making code easier to understand and work with.
On such stack class you’d have a class interface (for ease of use lateron) with some methods:
HorizontalStack.Add( a control or another stack)
HorizontalStack.Remove( by object reference or index)
Etc.
The auto layout could he some constraints (or a simpler way) that are added to the controls/stacks as get/set methods (class interface). This way we can get better automation and add more helpful classes in the future.
