Any new layout support in JUCE 4?


#1

I asked about complex GUI layouts several months ago, and thought I'd check in to see if there was anything new in JUCE 4.

I really don't want to hard-code pixel coordinates and sizes for everything, and I don't think I'm being lazy - that's just an antiquated way of building GUIs. There's a lot about JUCE I've really come to appreciate, but the lack of high-level layout still surprises me.

So, is there anything new in version 4? Should I write my own? I've done it before (a long time ago) for another framework, and I know I can do it, but it seems like it should be "part of the package".

Thanks!


#2

It's something we're definitely going to do this year, but there's nothing to share just yet!

If you have any particular requests or use-cases, let us know..


#3

I'm curious to know about your experience in high level layout functions programming. What did you do exactly with the other framework ? How do you position the objects in your UI with it ?


#4

My old system is quite simple, but it does the job. Basically, each component (views in my old system) can declare it's preferred size. For something like a button, this would be based on the length of the text label, in the UI font size.

Then, I had a class that arranges views horizontally or vertically. You can mix and match the horizontal and vertical arrangements, so for example you could have 4 views arranged horizontally, and the second view could actually be a collection of 6 views that were arranged vertically.

When placing views into the vertical or horizontal layouts you can specify whether the views should use their preferred size or stretch to the available space, whether they should be left/right/center aligned, stuff like that.

Finally, the layouts then handle the final sizing and alignment of everything based on the child views and sub-layouts.

Like I said, it's quite simple, but to me it's a huge step beyond pixel placement. Plus, with sizing based on strings, it handles localization very well. If a button label in one language is "XXX", but in another language is "XXX XX XXXX X", that simply changes the view's preferred size and the layout objects take that into account when placing views. So a dialog may be a different size in different languages, but everything will still fit and be aligned relative to each other.


#5


I actually quite like the Introjucer GUI-Editor. Many here seem to complain about it, but I find it actually quite usefull. Also artists can tweak the layouts as they wish without support from programmers.

I like it, because it's simple. Unfortunately not everything can be done with it (without adding dummy componentes or putting stuff in subcomponents.

What I'd like to see though are quick, graphical buttons for "subtracted from width of parent, anchored at right of component", etc. (Like autosizing in Apples Interface Builder or something like that). currently it's way more klicking than neccessarry.

Also loading a custom look-and-feel from a dll (plugin-mechanism) would be awesome to make it more WYSIWYG. I ment to prepare a patch for that, but got side-tracked.

I'd also like to see more components supported. I'm currently using Generic-Component when creating TableListBoxes, MidiKeyboardComponents, etc.

In this case I prefer simple over powerful, because I really hate fighting with Layout editors that try to be too smart.


Best,
​Ben
 


#6

My old system is quite simple, but it does the job. Basically, each component (views in my old system) can declare it's preferred size. For something like a button, this would be based on the length of the text label, in the UI font size.

Then, I had a class that arranges views horizontally or vertically. You can mix and match the horizontal and vertical arrangements, so for example you could have 4 views arranged horizontally, and the second view could actually be a collection of 6 views that were arranged vertically.

When placing views into the vertical or horizontal layouts you can specify whether the views should use their preferred size or stretch to the available space, whether they should be left/right/center aligned, stuff like that.

Finally, the layouts then handle the final sizing and alignment of everything based on the child views and sub-layouts.

Like I said, it's quite simple, but to me it's a huge step beyond pixel placement. Plus, with sizing based on strings, it handles localization very well. If a button label in one language is "XXX", but in another language is "XXX XX XXXX X", that simply changes the view's preferred size and the layout objects take that into account when placing views. So a dialog may be a different size in different languages, but everything will still fit and be aligned relative to each other.

I see, interesting

Recently, I have started to use the class Rectangle <int> to avoid "pixel by pixel" positioning. I think I have seen that at first in JUCE demos code. The idea is that you define areas to set the bounds of your components, and then you can perform a few operations on them to remove sections or to make a component positioned starting from the center of your area or other components positions. I created also a very basic grid system...

I think we don't need a lot of extra functions to have a better layout definition scheme in JUCE... I have already done a few things that can be positioned depending on the current size of the main window which perform not too bad (but don't talk to me about the lost string sections at the JUCE Summit lol)


#7

I have a similar system, i just attach layout attributes (like simplified css) to components, also i can define a default size/bordersize for objects. In the resize callback the components will just aligned if there were on a html page.

 

 


#8

Like IvanC, I have been using Rectangles increasingly for layout. It's resulting in much cleaner code for me. My synth is resizable with many components of dynamic size, so by necessity my layouts must be responsive. I'm using Rectangle::removeFromTop() and similar to do most of my layout now. The removeFrom functions chop off a piece of the rectangle and return the chopped off part. A typical bit of layout code looks like this:

// Make a box with some padding:

auto bounds = getLocalBounds().reduced(4);

// Place a viewport component in the left half:

myViewport.setBounds (bounds.removeFromLeft (bounds.getWidth() / 2));

// Let's add some padding between the viewport and what
// we'll layout next:

bounds = bounds.withTrimmedLeft(4);

// Now in the remaining space, we lay out an OwnedArray
// of sliders vertically:

const int knobHeight = bounds.getHeight() / myKnobs.size();

for (int i = 0; i != myKnobs.size(); ++i)
    myKnobs[i]->setBounds (bounds.removeFromTop (knobHeight));

I'm extremely happy with how much more maintainable this makes my layout code. One thing I keep wishing for though is proportionOfWidth & proportionOfHeight methods on Rectangle so I don't keep having to do rect.getWidth() / 2 etc.


#9

I'd recommend basing it on the CSS Flexbox. It's super powerful. Then extending it for the specific case of grids, ala http://flexboxgrid.com/.

 


#10

What about if the JUCER_METADATA in any SomeGUIComponent.cpp, replaced by the component's constructor actual juce commands and, all this saved in a separate file named SomeGUIComponent_Design.cpp ?

Under this view :

- The actual juce commands can be used by Introjucer to show GUI elements at design time.
- The MainComponent.cpp file, will be smaller, more simple and managable (it will contains the code for events handling only).

 

Just a fresh(?) view....

 

George    

 


#11

Since programmers are some the worst designers in an application's team, it would be very cool to have something as advanced as QT's QML with quick layout, or even as elaborate and expressive as you.i engine with its Adobe After Effects parser (https://www.youtube.com/watch?v=I7Jj1g2qLxg).

As I personally want to spend more time on code itself, I'd love to be able to just let graphic designers do their thing, hand off their work and just plug it into the application for the fastest iteration possible - with the sleekest design.


#12

That's one of the ideas we're considering.


#13

hey guys,

love juce but feel also like its kind of old skool in gui responsive / dynamic gui stuff. would also like that u can implement responsive stuff super easy...

greetz equinox


#14

Yeah, our general plan is to do someting like flexbox.


#15

can you add something like this: 

http://principleformac.com/


#16

I'm with you on this one. The tools on Mac for GUI are soo flexible and so easy that a child could almost use. Just drag and drop and resize on the fly like a WSYWIG editor. 


#17

If there existed something like this for JUCE that worked for all platforms JUCE supported, it would be absolutely unstoppable. I can only image the insane amount of work it would take for that to happen though, and the likely price jump that would come with it (though I and I'm sure many others would happily pay for it). The unfortunate limitation I see with Principle (that JUCE wouldn't have) is being limited to Apple platforms.


#18

I took a look at Principle last week when this was posted, and while it does look pretty cool, as far as I can tell you can't actually build an app with it.

It appears to be a "design tool" where you can output a movie or animated GIF, or you can play with a design interactively using a special "player" app. But I couldn't find any indication that you could integrate one of these designs into an actual application.

There are a lot of these design tools out there. They're great for creating a mockup, showing to potential clients or investors, and making something that looks cool. But when it comes down to implementation, the poor engineers have to start from scratch to re-implement all the whizzy stuff the designers created.

If I'm wrong about Principle, please correct me. But I think it's a design tool, not a development tool.


#19

It would be sweet to be able to pass a float between 0 and 1, e.g.:

rect.setBounds(bounds.removeFromLeft(0.5f))

Maybe a float overload...?

π


#20

Whoa, you're right. For some reason I thought this could export code, given all the talk about iOS/OSX technologies in use under the hood. So it's a useful tool to help designers, but leaves the poor engineers banging their heads on the wall to implement a totally custom UI. Bummer.

I'd also like to toss out that Adobe is making an extremely similar tool, to be part of the creative cloud in the future:

http://blogs.adobe.com/creativecloud/update-on-project-comet-where-we-are-and-whats-to-come/