Live data from Hacker News

Yoga: A cross-platform layout engine

code.facebook.com

141–150 of 168 posts

Re: Yoga: A cross-platform layout engine

#141
post #89
post #62

One thing I've thought about recently is Facebook's Patent grants, and it's one thing that makes me uneasy about using any open source technology from Facebook like React (I currently do but am thinking to move to Preact because of the nicer MIT license and that it's analogous to React in many ways) because they're generally given a patent grant. I'm not a lawyer so I don't know if the grant would hold up in court si…

I am curious to hear of anyone who has reviewed this license with their lawyers / legal departments and received a positive, non-cautionary response to go ahead and use the software and libraries covered under it.

FYI, my React/Redux links list has a section pointing to discussion on the PATENTS license, including Facebook's official FAQ on the topic: https://github.com/markerikson/react-redux-links/blob/master... .

Re: Yoga: A cross-platform layout engine

#142
post #35

Earlier quoted context omitted.

(Original author of css-layout here) I've spend a few months playing with Cassowary before working on css-layout and had long chats with its creator Greg Badros and the people behind https://gridstylesheets.org/ . Cassowary underlying abstraction is a linear inequation solver. So you give it a bunch of constraints of the form ax + by + cz + d ## There are two innovations in Cassowary: 1) There's a concept of strength…

> There's a concept of strength (required, strong, medium, weak) which allows you to define which rules should be dropped in case of conflicts. [...] That said, I had to build a dedicated tool to show me which rules where overridden or why otherwise it was very hard to understand what happened when the layout didn't work as I expected. That sounds like "strength" was probably the wrong approach. Why not require the d…

For 1), those are not bugs but to simulate if then else. If the width is 2) The height of a text is not a linear function based on the width of the container. You can't say, the height of the text is 10px * number of characters * width of the container.

Instead, if you add a single more character that makes it go to the next line it's going to add a single lineheight.

So, you can't encode this inside of the simplex and you need to do it as a separate pass.

Re: Yoga: A cross-platform layout engine

#143
post #62

One thing I've thought about recently is Facebook's Patent grants, and it's one thing that makes me uneasy about using any open source technology from Facebook like React (I currently do but am thinking to move to Preact because of the nicer MIT license and that it's analogous to React in many ways) because they're generally given a patent grant. I'm not a lawyer so I don't know if the grant would hold up in court si…

"if I had a patent and Facebook infringed on it my license is terminated if I assert my patent rights against Facebook even if it is valid and doesn't pertain to specific React technologies."

Do you have a patent that Facebook might infringe on?

Re: Yoga: A cross-platform layout engine

#144
post #142

Earlier quoted context omitted.

> There's a concept of strength (required, strong, medium, weak) which allows you to define which rules should be dropped in case of conflicts. [...] That said, I had to build a dedicated tool to show me which rules where overridden or why otherwise it was very hard to understand what happened when the layout didn't work as I expected. That sounds like "strength" was probably the wrong approach. Why not require the d…

For 1), those are not bugs but to simulate if then else. If the width is 2) The height of a text is not a linear function based on the width of the container. You can't say, the height of the text is 10px * number of characters * width of the container. Instead, if you add a single more character that makes it go to the next line it's going to add a single lineheight. So, you can't encode this inside of the simplex a…

> Then problem is that if then else is not linear so you can't express this.

It sounds like a limited set of discontinuous functions are needed, like how media queries are used in CSS. The constraints to satisfy are defined by a set of top-level discontinuous functions on environmental parameters, but the set is always fixed so it's pretty simple to detect when you need to switch to a different set of constraints. Wouldn't that suffice?

> The height of a text is not a linear function based on the width of the container. You can't say, the height of the text is 10px * number of characters * width of the container.

For simplicity, let's take the easiest case of a fixed width font and we'll hard wrap at X characters, regardless of whitespace positions. The number of lines L and the height of the text H in px is then given by:

    L = char_px_width * char_count / container_px_per_line
    H = L * char_px_height
Agreed? If so, then that case isn't difficult, but difficulties arise when you want better wrapping behaviour based on whitespace with a non-fixed width font. I agree that doing it precisely with linear equations doesn't seem feasible, but it seems like we can closely approximate it to minimize the reflows needed to converge on the final result.

Suppose we set char_px_height=the widest character of the typeface (ditto for char_px_height) so we overestimate the dimensions needed. A quick google search suggests that the average word length for ordinary English is around 5 characters. So with avg_word_length=5, the above equation changes to something like:

    L = char_px_width * avg_word_length * ceiling(char_count / avg_word_length) / container_px_per_line
This should miss the actual number of lines needed at most by 1, except when dealing with highly irregular text. Then again, the avg_word_length can be constantly adjusted on the fly based on the reflows you have to do, so this should quickly converge too. Does this sound right?

Edit: sorry, that last calculation is obviously wrong, I was rushing out the door. The idea is to estimate number of lines from the average nnumber of words that would fit per line.

Re: Yoga: A cross-platform layout engine

#145
post #118

I like the concept and the C# code is just hands down the best example out of all of them (yet another reason I miss coding in C#). I'm curious though, will this be eventually ported to JavaScript? Yeah yeah I know "flexbox is already on the web!" but if you could write a layout in this fashion versus using style sheets then you could take it and directly apply it to any of your applications (even if you have to conv…

I believe the canonical JS implementation is (or will be?) https://github.com/jordwalke/ReLayout - written in Reason and compiled to JS via Bucklescript. Lots of very nice reasons and benefits for this, including readable JS with good performance.

Hi, I'm one of the contributors to ReLayout. I originally worked on ReactJS, and ReactNative which made use of Yoga (then, css-layout), and now I'm working on Reason and ReLayout (which is a port of Yoga to Reason). I definitely wouldn't call ReLayout the canonical way to compile Yoga to JS. While we intend to keep ReLayout up to date with the Yoga implementation, we're ultimately doing this because we'd like to experiment with combining ReactJS's API, the new Fiber architecture, with a deeply integrated Flex Box layout algorithm. Feel free to message us if you're interested in tracking the results of the experiment, but but for now, I'm just excited to see Yoga launch. The Yoga project and team have been incredibly helpful with our experiment and I'm excited to see more apps integrate Yoga going forward. Congrats! I can't go back to not using FlexBox now that I've gotten hooked on it. (edited: Formatting)

Re: Yoga: A cross-platform layout engine

#146
post #89
post #62

One thing I've thought about recently is Facebook's Patent grants, and it's one thing that makes me uneasy about using any open source technology from Facebook like React (I currently do but am thinking to move to Preact because of the nicer MIT license and that it's analogous to React in many ways) because they're generally given a patent grant. I'm not a lawyer so I don't know if the grant would hold up in court si…

I am curious to hear of anyone who has reviewed this license with their lawyers / legal departments and received a positive, non-cautionary response to go ahead and use the software and libraries covered under it.

I'm not able to name names, but legally speaking, it's no worse than MIT or BSD. Sure, there's a retaliation clause, but that's just affirmation of what companies who publish with the others aren't telling you.

In effect, it's more, not less, permissive and honest. INAL, but that's what I've been told by one.

Re: Yoga: A cross-platform layout engine

#147

Earlier quoted context omitted.

I think you're thinking of RelativeLayout? I don't have ConstraintLayout in my IDE right now, but RelativeLayout sounds like what you're talking about.

Nope, I am refering to ConstraintLayout. RelativeLayout does not use Cassowary (even though for an API consumer, this is just an implementation detail). Actually, CL one of the reasons behind the creation of RL is to improve on RL : - remove the need to nest for complex layouts. Nesting has some intrinsic measure/layout overhead. CL solves this by allowing way more types of relative constraint. The only remaining rea…

This is incredible! is this going to be paired with a wysiwyg tool... because i have a feeling that writing the constraints is going to get frustrating very quickly.

Re: Yoga: A cross-platform layout engine

#149
post #62

One thing I've thought about recently is Facebook's Patent grants, and it's one thing that makes me uneasy about using any open source technology from Facebook like React (I currently do but am thinking to move to Preact because of the nicer MIT license and that it's analogous to React in many ways) because they're generally given a patent grant. I'm not a lawyer so I don't know if the grant would hold up in court si…

Yes, given two libraries A and B, which are equal in all respects except one is encumbered with vague licensing talk, pick the one without! It's a good engineering practice, and it will ensure that we, as a community, evolve towards zero-licensing libraries.

Both React and hypothetical library B are encombered with possible Facebook patents. Only by using React are you assured that you aren't going to be in patent infringement with Facebook's patents given they provide you a license for React. By using Preact, you have no such patent grant.

Re: Yoga: A cross-platform layout engine

#150
post #124

Earlier quoted context omitted.

If you name React in your patent lawsuit against Facebook, your license for React is terminated. Other software licenses remained unaffected. That seems like a pretty reasonable stance for distributing an open source project.

Both you and grandparent are wrong. I have consulted with lawyers on this (and the language is pretty clear as well). If you initiate a patent lawsuit against FB on any grounds, you lose patent protection for this library (or React, Reactive-Native, etc -- they share the same patent licensing terms). If you counter-sue FB after they have initiated a patent suit against you, you are ok, as long as your counter-suit do…

It doesn't matter if you use React or not. If you sue Facebook, they can sue you for any patents they hold.
Post reply on HN