Updated to Juce 5.0.1-3 but quickly ran into this:
error: ‘void juce::Component::setBounds(const juce::String&)’ is deprecated
What is the recommended replacement? It should probably be noted in juce_Component.h. A grep of my code shows I’m using it in 720 places across 180 files. This is a significant amount of work. I hope the replacement is something simple I can swap in, because re-doing all 720 of these calls to setBounds() on dozens of windows is going to take forever!
Any particular reason why the relative rectangle setBounds() will no longer be supported? It seems to work well, and is easy to manage object sizes and positions in relation to each other when creating windows with lots of controls. In case I’ve misunderstood the deprecation message, this is how I use setBounds():
saveButton .setBounds( "parent.width - 70, 6 , left + 32, top + 32" );
printButton .setBounds( "pbsave.right + 2 , pbsave.top , left + 32, top + 32" );
lockButton .setBounds( "pbsave.left , pbsave.bottom + 2 , left + 32, top + 32" );
closeButton .setBounds( "pblock.right + 2 , pblock.top , left + 32, top + 32" );
And the static Rectangle::fromString() will work out all the relative positioning from the other components in the window? The documentation doesn’t indicate that is how it works. If so, then great, but somehow I doubt your suggestion will work.
All the RelativeRectangle stuff is a failed experiment I tried years ago… I know people are still using it so may eventually shuffle it into a module so you don’t have to rewrite your code, but I would like to remove it from the main codebase, and particularly from classes like Component, to discourage anyone new from using it.
It’s easy enough to replace - if you look at the actual method, it’s trivial:
It works OK for very simple cases, but doesn’t provide any advantage over what you’d write if you did it the old fashioned way in a resized() method. (And TBH if you write your resized() method using rectangle chopping, that’s more readable than this).
But more importantly there are vastly better ways to perform layout than this. We’ll be adding new paradigms this year, and I think it’ll be confusing to have this hanging around as an alternative, which is why we’ll phase it out.