4 ms·

As GUI dev who worked with Apple's AutoLayout extensively I can confidently say constraint-based layout is a trap. It looks like more intuitive way to go on sim

As GUI dev who worked with Apple's AutoLayout extensively I can confidently say constraint-based layout is a trap. It looks like more intuitive way to go on simple examples, but complexity spikes quickly as number of controls goes up. It's more complicated, more resilient to changes (harder to maintain), easy to get wrong, hard to understand and debug, bugs generally look uglier (what would be minor misplacement in CSS often becomes overlapping or clipping). It does not support word wrapping without hacks and restrictive assumptions about width. It is a real mess to insert/remove controls dynamically. Compared to previous experience with Qt, I don't see any advantage of constraint-based layout over box-based layout.

thewarrior 11y ago
I saw the headline , didn't even read the article and came here to say this and saw your comment. I've been struggling with auto-layout for about six months now. I finally get it but there's a certain impedance mismatch between how you want your elements to be laid out and what constraints are required to achieve the same result. Humans beings aren't wired to intuitively think like a constraint solver. I'm not an experienced developer but my thinking on this issue is that the platform should provide some functionality to achieve the most common boiler-plate layouts and anything more complex should be written in code. Usually constraints are simple and so are the layouts. But to achieve more complex layouts you need constraints which are at cross purposes to each other but have different priorities. It's not intuitive to work through this stuff. Here's an example : http://stackoverflow.com/questions/25766747/emulating-aspect-fit-behaviour-using-autolayout-constraints-in-xcode-6 http://stackoverflow.com/questions/25766747/emulating-aspect... The answer there is great but tell me , you could have aspect fitted the view to it's parent in just four lines of code instead of going through this confusing series of constraints. I was making a tic tac toe game and I decided to try and draw the boxes and lines using auto layout. The constraints were making me tear my hair out and finally I wrote 5 lines of custom layout code and it took me only ten minutes and this was after futzing about with the constraints for half an hour and it did what I wanted to on an iPhone , iPad and for any height or width. I personally believe in a simplified version of FlexBox for common cases (yes I think it needs to be even simpler) and custom code for anything more complex. Bringing in all the baggage of a constraint solver to do your layout is like trying to use an Abrams Tank to kill a mouse.
- murbard2 11y ago
  Perhaps the right approach would be to still use constraints to describe the layout, but to infer those constraints from examples provided interactively by the designer. The workflow would be: 10 designer creates an initial mock-up 20 designer re-sizes the window / uses another device 30 designer alters the style on that new format, re-sizing boxes, changing font sizes, etc. 40 constraint solver finds a minimal set of constraints consistent with the designer wishes 50 goto 20
  - masklinn 11y ago
    Some sort of genetic constraint generator, where the fitness function is examples provided by designers?
    - murbard2 11y ago
      The examples are meta-constraints. The fitness function is the parsimoniousness of layout constraints, under the constraint that they reproduce the examples.
- waynecochran 11y ago
  Yes. Even though I understand the math and the concepts for iOS's constraint based layout, I have found it amazingly difficult to use in practice. In IB, if you set one thing wrong suddenly many of your view's just disappear ... "undo" (or just starting over from scratch) is frequently employed. Debugging is a nightmare ... some cases I never figured out: http://stackoverflow.com/questions/28550692/auto-layout-of-views-stacked-top-bottom-portrait-and-left-right-landscape http://stackoverflow.com/questions/28550692/auto-layout-of-v...
archagon 11y ago
I agree with your assessment, but for certain use cases, I've found it to be pretty useful. Box-based layout forces you to arrange your view hierarchy in a Towers of Hanoi kind of way, whereas constraint-based layout lets you define relationships between free-floating sibling views directly. Here's[1] a little test I recently worked on; the amount of code to do this was pretty small and conceptually simple. [1]: https://github.com/archagon/ABExpandingViewController/blob/master/demo2.gif https://github.com/archagon/ABExpandingViewController/blob/m...
specialist 11y ago
Agreed. The correct answer (for desktop) is canonical grid based layout. (1) I created DesignGridLayout, a manager for Java Swing. You add rows of widgets, the manager figures out optimal placement. https://designgridlayout.java.net/grids.html https://designgridlayout.java.net/grids.html Every time I see mention of grids and CSS, I get a little bit excited. Then I see it's not based on canonical grids and I leave sad. Maybe I should have "ported" DGL to HTML/CSS/JS, but I haven't figured out how (yet). For mobile, I reserve judgement. I've heard good things about AutoLayout. But it'll be hard to replace my strategy of creating custom managers as needed. (1) Except maybe for dynamic insertion and removal of controls. I'd have consider a few cases.
ux-app 11y ago
When I first heard of GSS I thought it was the holy grail of layout systems for app (not document) layout. On the surface, and as you mention, with simple examples it is deceptively alluring. However it quickly becomes apparent that the issues with regard to bugs and broken/cyclical dependencies far outweigh any benefits the system brings. Maybe a hybrid approach would be best? Constraint-based for the broad strokes and then regular box-based layout within these blocks.
joegyoung 11y ago
My wife and I had a big fight several years back because of photoshop. She was a photographer and she wanted to know the constraints of an image in inches and resolution. I told her that those didn't count for screen use and to just use the height and width in pixels. She had not understood until she googled it and watched a youtube video.

thewarrior 11y ago

I saw the headline , didn't even read the article and came here to say this and saw your comment. I've been struggling with auto-layout for about six months now. I finally get it but there's a certain impedance mismatch between how you want your elements to be laid out and what constraints are required to achieve the same result. Humans beings aren't wired to intuitively think like a constraint solver. I'm not an experienced developer but my thinking on this issue is that the platform should provide some functionality to achieve the most common boiler-plate layouts and anything more complex should be written in code. Usually constraints are simple and so are the layouts. But to achieve more complex layouts you need constraints which are at cross purposes to each other but have different priorities. It's not intuitive to work through this stuff. Here's an example : http://stackoverflow.com/questions/25766747/emulating-aspect-fit-behaviour-using-autolayout-constraints-in-xcode-6 http://stackoverflow.com/questions/25766747/emulating-aspect... The answer there is great but tell me , you could have aspect fitted the view to it's parent in just four lines of code instead of going through this confusing series of constraints. I was making a tic tac toe game and I decided to try and draw the boxes and lines using auto layout. The constraints were making me tear my hair out and finally I wrote 5 lines of custom layout code and it took me only ten minutes and this was after futzing about with the constraints for half an hour and it did what I wanted to on an iPhone , iPad and for any height or width. I personally believe in a simplified version of FlexBox for common cases (yes I think it needs to be even simpler) and custom code for anything more complex. Bringing in all the baggage of a constraint solver to do your layout is like trying to use an Abrams Tank to kill a mouse.

murbard2 11y ago
Perhaps the right approach would be to still use constraints to describe the layout, but to infer those constraints from examples provided interactively by the designer. The workflow would be: 10 designer creates an initial mock-up 20 designer re-sizes the window / uses another device 30 designer alters the style on that new format, re-sizing boxes, changing font sizes, etc. 40 constraint solver finds a minimal set of constraints consistent with the designer wishes 50 goto 20
- masklinn 11y ago
  Some sort of genetic constraint generator, where the fitness function is examples provided by designers?
  - murbard2 11y ago
    The examples are meta-constraints. The fitness function is the parsimoniousness of layout constraints, under the constraint that they reproduce the examples.
waynecochran 11y ago
Yes. Even though I understand the math and the concepts for iOS's constraint based layout, I have found it amazingly difficult to use in practice. In IB, if you set one thing wrong suddenly many of your view's just disappear ... "undo" (or just starting over from scratch) is frequently employed. Debugging is a nightmare ... some cases I never figured out: http://stackoverflow.com/questions/28550692/auto-layout-of-views-stacked-top-bottom-portrait-and-left-right-landscape http://stackoverflow.com/questions/28550692/auto-layout-of-v...

archagon 11y ago

I agree with your assessment, but for certain use cases, I've found it to be pretty useful. Box-based layout forces you to arrange your view hierarchy in a Towers of Hanoi kind of way, whereas constraint-based layout lets you define relationships between free-floating sibling views directly. Here's[1] a little test I recently worked on; the amount of code to do this was pretty small and conceptually simple. [1]: https://github.com/archagon/ABExpandingViewController/blob/master/demo2.gif https://github.com/archagon/ABExpandingViewController/blob/m...

specialist 11y ago

Agreed. The correct answer (for desktop) is canonical grid based layout. (1) I created DesignGridLayout, a manager for Java Swing. You add rows of widgets, the manager figures out optimal placement. https://designgridlayout.java.net/grids.html https://designgridlayout.java.net/grids.html Every time I see mention of grids and CSS, I get a little bit excited. Then I see it's not based on canonical grids and I leave sad. Maybe I should have "ported" DGL to HTML/CSS/JS, but I haven't figured out how (yet). For mobile, I reserve judgement. I've heard good things about AutoLayout. But it'll be hard to replace my strategy of creating custom managers as needed. (1) Except maybe for dynamic insertion and removal of controls. I'd have consider a few cases.

ux-app 11y ago

When I first heard of GSS I thought it was the holy grail of layout systems for app (not document) layout. On the surface, and as you mention, with simple examples it is deceptively alluring. However it quickly becomes apparent that the issues with regard to bugs and broken/cyclical dependencies far outweigh any benefits the system brings. Maybe a hybrid approach would be best? Constraint-based for the broad strokes and then regular box-based layout within these blocks.

joegyoung 11y ago

My wife and I had a big fight several years back because of photoshop. She was a photographer and she wanted to know the constraints of an image in inches and resolution. I told her that those didn't count for screen use and to just use the height and width in pixels. She had not understood until she googled it and watched a youtube video.