Breaking changes

1

I’m not sure what to think of this

Change
------
FlexItem::alignSelf now defaults to "autoAlign" rather than "stretch".

Possible Issues
---------------
FlexBox layouts will be different in cases where FlexBox::alignItems is set to
a value other than "stretch". This is because each FlexItem will now default
to using the FlexBox's alignItems value. Layouts that explicitly set
FlexItem::alignSelf on each item will not be affected.

Workaround
----------
To restore the previous layout behaviour, set FlexItem::alignSelf to "stretch"
on all FlexItems that would otherwise use the default value for alignSelf.

Rationale
---------
The new behaviour more closely matches the behaviour of CSS FlexBox
implementations. In CSS, "align-self" has an initial value of "auto", which
computes to the parent's "align-items" value.

Don’t the JUCE devs have better things to do than breaking perfectly working apps with this kinda stuff? Sure there must be more important bugs to fix than tweaking some defaults in a way that will break working apps.

2

juce::FlexBox is intended to copy the behaviour of CSS’s flex-box. Previously, it didn’t properly follow the CSS standard because some of the defaults were incorrect - this was a bug in JUCE. That bug is now fixed as JUCE properly follows the CSS flex-box standard.

Any code that relied on the buggy JUCE code will indeed have broken (hence the addition to the breaking changes file). Since that user code was relying on library code being implemented incorrectly, it is therefore itself buggy.

It makes the library easier to maintain - since the behaviour of a flex-box is already well defined - and makes the API easier to learn as it’s much simpler to say "juce::FlexBox follows the CSS standard" than it is to say "juce::FlexBox is similar to CSS but with some differences that you’ll just have to figure out for yourself"

3

That is just ridiculous. To say JUCE is buggy and that therefore my code is buggy, because it doesn’t comply with some web standard - which it has nothing to do with - is just not justified.

The suggested workaround doesn’t seem to work. Setting alignItems or alignSelf seems to have no effect on the now broken layout.

4

Enough updates for now. I’m back in 6.1.2.

5

Flex-box is a web concept though, that’s where it came from. The intention was always for juce::FlexBox to copy the CSS flex-box. @jules made a lot of comments about grid and flex-box around the time it was added to the web, and just before it was added in JUCE, for example:

I totally understand that it’s frustrating for something to have changed to ‘fix’ something that’s not risk, but changes like this put the framework in a better place for the future.

For the record, I asked for these changes to be made here:

I wanted the correct behaviour because I’ve been writing a module that simplifies UI development and discovered these issues when I was comparing CSS layouts to the equivalent JUCE ones.

2 Likes
6

Sure there must be more important bugs to fix than tweaking some defaults in a way that will break working apps.

Compared to my experiences with other frameworks in other languages, my impression is JUCE is very conservative with deprecations and removals. Breaking changes seem well communicated. The breakage surface area seems pretty manageable. Hitting an upgrade snag is never fun — but when 80% of an app’s heavy lifting is being done by the framework, I think it’s reasonable that updating might require a bit of work by the dev.

I’ve posted this on the forum before, but I’d love to see defaults for UI (text/shadows/blur) updated to match modern conventions/expectations/80% use cases. I think this would help greatly with onboarding newcomers to the framework. IMO the web is a fantastic reference implementation for these sorts of things.

9 Likes
7

I do appreciate your points. Its of course good if the framework is compatible with the rest of the world. I’m just not 100% sure that the way this has been ‘fixed’ is the right one. To me JUCE defines and implements its spex and i make my code work with that. If JUCE then changes the spex to comply with some other spex (e.g. CSS), its something else than fixing a bug. Correct me if i’m wrong, but JUCE does not input CSS?

Anyway, i’ve found a fix to my layout. Which left me a bit confused about the announcement and the sugested fixes for backwards compatibility. I’m finding hard time understanding these:

FlexBox layouts will be different in cases where FlexBox::alignItems is set to
a value other than "stretch".

To restore the previous layout behaviour, set FlexItem::alignSelf to "stretch"
on all FlexItems that would otherwise use the default value for alignSelf.

AFAIK in my case both the FlexBox alignItems and FlexItem alignSelf were on default values and the proper fix was simply to set FlexBox alignItems to center. It is very difficult to understand this from the suggested workaround. Was the previous default for FlexBox alignItems really stretch?

The problem might well be in my end, but just in case the info is incorrect.

8

It seems that FlexBox alignContent had prviously the same effect. I had this set to center and now i need to set alignItems to center. Maybe there are some more changes than those mentioned in the announcement.

[EDIT: changed justifyContent to alignContent]

9

The documentation for alignContent says “This property has no effect on single line layouts.”. Testing on DemoRunner 6.1.2 it definitely does.

10

My take on this, as the person who made this change, is that the FlexBox is quite clearly supposed to emulate the CSS FlexBox rules. All of the properties and property values share the same names (although adjusted to match JUCE style) as those of the CSS FlexBox. In addition, the docs for the class say

To use this class, set its parameters appropriately (you can search online for more help on exactly how the FlexBox protocol works!)

If the JUCE FlexBox spec were its own standalone thing, this wouldn’t make any sense. Searching online doesn’t return any results about using the JUCE FlexBox impl specifically, but it does return lots of results about the CSS FlexBox.

Given that it’s reasonably easy for existing code to be adapted to the breaking change, and that compatibility with the CSS spec has substantial benefits (existing CSS documentation can be applied to the JUCE FlexBox; designs and knowledge can be transferred from the web to JUCE with low overhead), I believe that making the change was the right thing to do.

You can see the change here:

I think this means “forced single-line” (i.e. flex-wrap: nowrap) rather than “all items happen to fit on a single line” (i.e. wrap or wrap-reverse). If I set flex-wrap: nowrap in the demo, then the align-content control doesn’t have any effect. Perhaps the docs could be a bit clearer here.

5 Likes
11

@reuk Fair enough. Good work for that part! I think we can narrow down the scope of my anxiety to this statement “Given that it’s reasonably easy for existing code to be adapted to the breaking change”. This wasn’t exactly the case for me as the instructions didn’t apply at all.

Thanks for explaining the “single line”. I was guessing that had something to do with this. The behaviour of alignContent hasn’t changed with respect to “This property has no effect on single line layouts” but there seems to be some change in how setting this property to center no longer causes the layout not to stretch the items. Previously this property was able to override both of the align properties and this is no longer the case. The description for the breaking change doesn’t mention this.