Attributes on the left side in EVFL

[NonLogicalDev]

Attributes on the left side in EVFL

[NonLogicalDev]

I dont see any way to select the attribute to constrain on the left side.

It would be nice to be able to add constraints such as

view1.centerX(==view2.centerX)

or something that is probably even simpler to parse:

A: view1.centerX == view2.centerX

Arguably it is not much harder to just add an explicit constraint with code, but this would be a rather neat addition, as it will allow people to prototype faster with the auto layout live editor.

[IjzerenHein]

Hi,

Yeah using (E)VFL you can't really do that. You can reference the .centerX attribute inside the width constraint expression, but that's not a useful case really. You could do it by manually though by creating a constraint which uses both attributes as centerX and add that to a View:

view.addConstraint({
  view1: 'view1',
  attr1: 'centerX',
  relation: 'equ',
  view2: 'view2'
  attr2: 'centerX',
});

Alternatively, EVFL supports a syntax for centering contents, like this:

H:|~[view(100)]~|

Each instance of ~ is given the same width, which automatically causes the contents to be centered. You can also use ~ more than twice to evenly justify multiple views: H:|~[view1(50)]~[view2(view1)]~|

Would this solve your problem?

cheers

[NonLogicalDev]

Tell me what you think of this idea, this could be enabled by adding a superpower flag in the options if (E)VFL is a standardized language and should not have additional definitions in it. But I think there is a benefit to having this in the language, it is a lot less verbose than doing it programmatically with addConstraint()

[IjzerenHein]

In general, I like it! I'll have a closer look at when I have some more time and get back to you.
cheers

[IjzerenHein]

Hi, I like this idea and have merged it into the repo. Next time please create a pull request on the develop branch as specified in CONTRIBUTING.md.

I like this because it gives you power of defining constraints that are otherwise impossible to make with EVFL. And it's good to not have to leave the EVFL world whenever a particular layout or rule can not be expressed in it. On the other hand, we need to be careful and not get carried away using this. It goes into the idea of the original VFL as it is no longer "visual". Basically this is just a way of explicitely defining Constraints within the VFL syntax. Because of this I would rather use the prefix C: instead of A:. When reading the line from left to right you could read "I Constraint child.bottom to child4.bottom", which I think makes more sense.
Also, it would be really useful if it were possible to define multiple constraints within a single line, like this:

C:child5.bottom(==child4.bottom),child5.centerX(==child4.centerX)

what are your thoughts on this?

cheers

[IjzerenHein]

Oh and I also like this syntax view1.centerX(==view2.centerX) over view1.centerX==view2.centerX.
Using the first syntax it's also possible to create multiple constraints easily. I wrote a test case for this and this already works:

C:view1.centerX(view2.centerX,view3.centerX,view4.centerX)

And one could become even bolder and support these exotic constructs:

C:view1.centerX(view2) // because view2 has no attribute, the attribute is derived from the left expression part (centerX)
C:view1.centerX(view2,view3,view4) // multiple constraints, derived attributes
C:view1.centerX(view2..8) // use of the spread operator to create multiple constraints
C:view1.centerX(view2..8.centerX) // spread and attribute combined

What do you think?

[NonLogicalDev]

I agree with the sentiment partially that VFL should not lose its Visual part too much, but I think even so having only one type of declarative statements would not hurt it too much, and with that one type we can practically cover the entire set of imaginable usecases, so I think it is a good tradeoff.

I also agree that supporting the spread operator and derivation from the left would make the language a lot more concise.

That said I would refrain from making multiple constraints per line perhaps, unless the syntax will only allow one left element to be constrained by allowing chaining, otherwise it can get confusing.

child5.centerX(view1).width(view2*2).height(child5.width/2)

I can help implement some of that, but a fair bit later, as I am very busy at the moment.

[IjzerenHein]

I like that chaining syntax, it is still very readable. Alright lets agree on choosing the chaining instead of the comma separated multi-constraint syntax.

So to recap, this would be how the final syntax would look like:

C:view1.centerX(view2.centerX) // explicit single constraint
C:view1.centerY(view2) // derived attribute
C:view1.centerX(view2..8.centerX) // spread operator
C:view1.centerX(view2..8) // spread operator, derived attribute
C:view1.centerX(view2.centerX,view3.centerX) // multiple views
C:view1.centerX(view2,view3) // multiple views, derived attributes
C:view2.centerX(view2).centerY(view2) // chaining syntax

Just let me know in case you start coding with this. I'm also busy but will let you know in case I start coding so we don't write any code twice.

cheers

[IjzerenHein]

Hi, I've released a new version of autolayout.js (v0.6.0) which supports the explicit constraint syntax.
Chaining is also supported but the spread-operator is not. The final syntax is:

C:view1.centerX(view2.centerX)     // view1 is horizontally centered to view2
C:view1.centerX(view2)             // attribute is inferred when omitted (centerX)
C:view1.centerX(view2).bottom(view2.bottom) // chaining syntax
C:view1.height(view2.width*2+10)   // expressions