I apologize ahead for a dumb question, but what exactly is the pipe brackets syntax used in Constraints definition. For example (taken from docs):

let mut solver = Solver::new();
solver.add_constraints(&[window_width |GE(REQUIRED)| 0.0, // positive window width
                          box1.left |EQ(REQUIRED)| 0.0, // left align
                          box2.right |EQ(REQUIRED)| window_width, // right align
                          box2.left |GE(REQUIRED)| box1.right, // no overlap
                          // positive widths
                          box1.left |LE(REQUIRED)| box1.right,
                          box2.left |LE(REQUIRED)| box2.right,
                          // preferred widths:
                          box1.right - box1.left |EQ(WEAK)| 50.0,
                          box2.right - box2.left |EQ(WEAK)| 100.0]).unwrap();

It's not a bitwise OR operator, and it doesn't seem to be an alternative pattern matching either. So, what an ENUM is doing between those pipe brackets, and how does it work?

Hi,

I've open a PR to add this repo to http://overconstrained.io/

Overconstrained/Overconstrained#13

Do not hesitate to close it if you don't want more visibility or comment it if you want to change something.

I just wanted to mention here that I've forked this repo to https://github.com/schell/casuarius. Our versions have diverged quite a bit and I don't want to put extra burden on maintaining this original repo. Thanks again for the great implementation :)

I'm trying to find a maximal solution for my problem. I found an example where they maximize P here, which translated to Rust would be:

let p = Variable::new();
let x = Variable::new();
let y = Variable::new();

let mut solver = Solver::new();
solver.add_constraints(&[
    p |EQ(REQUIRED)| x * -3.0 + y * -4.0,
    x + y |LE(REQUIRED)| 4.0,
    x * 2.0 + y |LE(REQUIRED)| 5.0,
    x |GE(REQUIRED)| 0.0,
    y |GE(REQUIRED)| 0.0
]).unwrap();

println!("Values:");
println!("P: {}", solver.get_value(p));  // -15
println!("x: {}", solver.get_value(x));  // 1
println!("y: {}", solver.get_value(y));  // 3

Except, I don't know how to specify that I want to optimize for P. I should get the values P=-16, x=0, y=4. How can I get similar results using your Cassowary crate?

Are you looking for maintainers?

I am using edit variables to add variables that represent the width and height of the UI viewport. I am thinking these should probably be of REQUIRED strength, but the solver doesn't seem to accept this strength on edit variables.

If the size of the viewport is not required, I think I might sometimes get strange results where the solver decides to change the viewport size. This isn't supposed to happen. Do you have any ideas what I might do here?

It doesn't look like Arc's semantics are ever used - is there a reason it should be?

pub struct Constraint(Arc<ConstraintData>);