Auto Layout for desktop?

General
21

Indeed, Auto Layout fixes it quite nicely.

In this example, since there are only three rows and two columns, admitting the space between controls and margins is constant, a simple division of the width and height will do for listboxes dimensions.

Something like this :

thewidth = (self.width-(spacer3))/2
theheight = (self.height-(spacer4))/3

Then you could do some autolayout stuff, making controls relative to each other

If you number listboxes in columns top to bottom 1,2,3 then 21, 22, 23 :
LB1.left = spacer
LB2.left = spacer
LB2.left = spacer

LB1.Top = spacer
LB2.Top = LB1.Top+LB1.Height+spacer
LB3.Top = LB2.Top+LB2.Height+spacer

Now labels (assuming they do not grow)

Label1.Left = LB1.Left
Label1.Top = LB1.Top-Label1.Height
Label2.Left = LB2.Left
Label2.Top = LB2.Top-Label2.Height
Label3.Left = LB3.Left
Label3.Top = LB3.Top-Label3.Height

Second row left is relative to LB1
LB21.Left = LB1.Left+LB1.width+spacer
LB22.Left = LB1.Left+LB1.width+spacer
LB23.Left = LB1.Left+LB1.width+spacer

Then you do the same for vertical spacing as in the first column

LB21.Top = spacer
LB22.Top = LB21.Top+LB21.Height+spacer
LB23.Top = LB22.Top+LB22.Height+spacer

Now labels (assuming they do not grow)

Label21.Left = LB21.Left
Label21.Top = LB21.Top-Label21.Height
Label22.Left = LB22.Left
Label22.Top = LB22.Top-Label22.Height
Label23.Left = LB23.Left
Label23.Top = LB23.Top-Label23.Height

This may look kind of tedious. With autolayout in iOS, you would have to set the relative to controls in each listbox inspector along the same principle. In essence, it is just as much work…

22

Your approach above is what I’m doing. I disagree that setting up the properties in autolayout is just as much work - but then again I’m used to doing it in XCode for some time now for old iOS projects.

23

XCode auto layout and Xojo auto layout are somewhat different.

Sure, when Auto Layout arrives in desktop, it will rock. And plenty of people will be awfully confused…

In the meantime, quite frankly, creating the code in resizing is not exactly hard labor…

24

True, creating the code for the resizing event for this specific container control is not really a big deal. But my app has several dozen container controls, all of which will have similar needs to resize their contents, and some of which have tricky contents to manually do the math for all the time.

Adding up all the time I will have to spend both considering the right way to get things to size, and then coding it all up is substantial enough I wanted to just make some noise to see where things stand. Looks like I’m headed for a lot of tedious and repetitive grinding out of code to position things all over the place.

25

Auto Layout and full Retina / HiDPI support are my 2 largest wishlist items at the moment.

26

If anyone is interested in throwing some weight behind getting AutoLayout available on the desktop, I’ve created a feedback request for it:
<https://xojo.com/issue/38221>

27

I am afraid you are looking at Auto Layout with XCode glasses. At the moment, Xojo Auto Layout does not deal with content at all. Neither to modify it according to control size, or to autosize controls according to content.

What it does is to let you decide for each control to what it is relative to left, Top, and/or right and bottom. I believe it should be possible to create a subclass of control that was at least able to self-position towards to control left or control above, and fetch its size from a window property. Such a modest automation would alleviate a very big part of positioning.

I even think it would be possible to create control computed properties containing elaborate constraints such as “left = LB1.Right+spacer” which would parse the constraint and apply it automatically. But then it would be called auto layout :wink:

I have implemented autosize a while ago for subclassed text controls that grow relative to content. It seems doable to render a subclass of listbox aware of internal resizing rules.

All that not to say your FR is not necessary. Just that it may take a while before Auto Layout comes to desktop. In the meantime, we might as well find ways to do without.

28

FWIW: I have created a NSLayoutConstraint class for OS X. But making it really work is something is wasn’t able to do. I don’t know if it’s a Xojo controller interfering or my inability to set usesConstraintBasedLayout to true – alternatively it doesn’t work at all or it works by modifying the wrong view – a window stays twice the size of a control’s width instead of the control changing size with changes of its window’s width. I usually prefer the native solution whenever possible but in this case I wonder if a Xojo control wouldn’t be better – OS X constraints will at least need much more time for experiments.

29

I would not speak for NSLayoutConstraint which indeed may interfere with the Xojo framework.

I have implemented it in RubberViewsWE in pure Xojo code, and that same code can be adapted fairly easily to Desktop.

Even if you do not program in Xojo Web, maybe you want to have a look at the “Auto Layout Only” page of the app at http://rubberviews.com/cgi-bin/rubberviewswe/rubberviewswe.cgi

Now, as much as Auto Layout is mandatory in iOS, and in Xojo Web very useful for the more than half users who surf on mobiles, it is a lot harder to master than regular left, top, width and height. To take an example, the auto layout page of the app I link to has only a dozen controls, and the total number of constraints is about a hundred lines long.

Desktop essentially needs to deal with the resolution range. That entails not only shuffling controls around, but also managing content relative to screen size.

30

It is. The control locking mechanism kicks in on window resize, which won’t play well with AppKit’s auto layout.

31

Thanks, Joe. That’s how it felt! I thought I could get rid of it by setting each lock to false, but that isn’t succesful. So far, I can only lock the size of a window by its content – which is not exactly what I was looking for :wink:
Is there be a way to disable the locking mechanism or would it only be possible by custom window classes? (Still hoping for a DesktopUserControl object like in iOS – creating custom controls without replacing the original view is a bit mind-bending.)

Yes, I can confirm that. ConvertARMMaskToConstraints presented me with an array of more than 20 constraints for only two controls placed on a window. Doesn’t make debugging that easy.

32

It is amazing to read again this thread. I had forgotten a big part of it. Especially the post where I point out how useful Auto Layout could be for Xojo Web…

Now, there is another part which I did not implement (yet) :

[quote=59539:@Geoff Perlman]Different controls sizes for different localizations
That last one is really important for apps that are localized into multiple languages. You often end up having to create a layout that works for all languages but is not ideal for any one of them. Auto-layout completely solves this problem.[/quote]

This part has not been implemented in iOS Auto Layout so far, I believe.

For years VB had the AutoSize property for labels and TextFields, where the control grows relative to content. That does not seem out of this world to implement, but it implies being able to fix limits beyond which a control should not grow. Same thing for height and multiline. Or, should font size be reduced automatically after a point.

Having adapted numerous programs originally in English to French, I am quite familiar with text growth in localization. Auto Layout can probably indeed solve a lot of cases. But it will take a lot of getting used to. In of itself, it is almost a new programming language.