On the develop branch we’ve pushed an implementation of a JUCE FlexBox implementation: FlexBox and FlexItem are the classes involved, and I’ve added a demo page to the big demo app that shows some basic tests.
We’ve not had chance to do a tutorial yet, or even to use it in any of the rest of our code, but would be interested to know what you guys make of it, especially if you’re already familiar with FlexBox on the web. Keen to know if you think the way we’ve done it is easy to use, or could be improved with extra helper methods/classes etc.
Oh, and I should mention that these classes are C++11 only, so if you’re using an older compiler, you won’t get them. That’s probably a policy we’ll be mostly adopting for new chunks of code that we add, but I doubt if it will impact many people.
Would love to do so. Do you plan to put the API-doc online as well?
To save people from confusion you might consider either a dropdown-menu on the api-docs or at least have two subdirs for develop and master, as long as there are these differences.
And while you’re at it, how about fixing the search and inheritance diagrams (will keep pointing that out, sorry, if you feel bugged, that’s intentionally)
Watched the demo and already like it. I didn’t use flexbox yet, so I can’t comment on that, but the change from QtDesigner I used 10 years ago seems to be easy…
Is there a serealization planned or even already possible, so the layout can be loaded and saved separately? Would be perfect for e.g. the drag and drop of toolbars etc.
Nothing like that in there yet, but loading them from XML/ValueTrees shouldn’t be hard to add. Would be interested in the use-cases that people find for it, to decide how best it could be extended.
In juce_gui_basics, the inclusion of FlexBox & FlexItem is wrapped in the JUCE_COMPILER_SUPPORTS_MOVE_SEMANTICS preprocessor definition. I am using VisualStudio 2012, which apparently supports move semantics. Thus, the headers and implementation files are included in my project. However, in the FlexBox implementation file, alias are used. I don’t believe this is supported in VisualStudio 2012.
There is also an issue initializing non static const integral data members (compiler error C2864) in the FlexItem header.
Would it be possible to wrap the inclusion of the FlexBox in a preprocessor definition that matches the required compiler feature(s)?
With no VisualStudio 2012 build for the Projucer, I guess I should consider a newer compiler.
An interesting use-case for adding serialization is de-coupling of the app layout design and the app implementation so that it is easier to delegate layout design to non-programmers. If layout sizes/constraints/orders can be read from file, this should be fairly easy to accomplish.
Finally got to testing these. These seem rather nice to do some layouting.
However, I wonder if support for hiding/reshowing items with corresponding changes in the layout could be incorporated into these classes. Setting the visibility of the associated components to hidden of course just leaves an empty space in the Flex layout instead of making more space for the rest of the items.
I don’t think that’s something we’d want to build into the classes themselves, but you’d get the same effect by just not adding any invisible components to the FlexBox::items list.
