No, it’ll need to be reviewed and JUCE-ified first. We’re all pretty busy at the moment so I’m afraid I can’t give an accurate estimate when this will be but I will try to get around to it soon.
Badly needed Layout features : Control Alignment and multiple-highlighted component property editing
understood.
This is very interesting. I hear that the JUCE team is very busy, but these additions would be extremely welcomed. I’m rooting for these to be added into the library.
1 Like
if you can’t wait there is a copy of my own build of PROJUCER - with the changes discussed - in that DROPBOX link i shared earlier in the thread.
All the caveats apply of course… but for the time being i’m going to be using that version myself. “eating one’s own dog food” as they say…
Do bear i mind - its only a subset of all the multiple-select features I would have liked. ( the spacing stuff for example - but thats better left to FlexBox ).
I did want to implement multiple-object-resizing by means of mouse-drag but couldn’t get my head around it in the time i’d allowed myself to work on this stuff, away from my own work.
Hey, any additions you have spent time on are much appreciated, even if it doesn’t cover the full spectrum of what other GUI editors can do, anything to make the WYSIWYG editor more powerful, I see as a great help. Thank you very much @dstenning. I know some mods on this forum have dismissed the usefulness of the GUI editor and say it belongs in the past, but I, as a newer dev to GUI coding, use it all the time, and a few of my good friends who earn a living through the plugins they make with JUCE swear by it. I still implement some components and ideas strictly through code, but if I can save time by using the editor, I will.
1 Like
many thanks joe.
i’ve just fixed a bug to do with left-alignment of selected objects in my modified PJ code where align left caused objects to slam hard to the left of the window instead of aligning where they stand. Its been committed and pushed to my GIT branch - but if you happen to have already downloaded my version from DropBox there’s now and updated version of it - with this bug fixed. Its worth downloading.
I’ve taken a look at your changes and can’t get the alignment to work. When opening up the GUI editor in the HelloWorld example and selecting both the label and button and attempting to align them using any of the commands they don’t align themselves correctly. It looks like this is because your changes don’t take into account the relative positioning options - if you click on the ‘mode’ button next to any of the component dimension properties you can see the list of options for how a component should be positioned:
Your alignment options won’t be correct if you use these for positioning components.
1 Like
thanks for taking the time to do that.
I’ll fix it soon as i can and report back when done.
I’ve spent a little time this morning coming up with my own method for alignment in the GUI editor based on your pull request. It seems to work fine and responds correctly when components are relatively positioned. I’ll do a bit more testing and cleanup and should hopefully have something pushed to the develop branch soon.
1 Like
Oh thats great to hear. Hadnt gotten around to it - and for sure would have taken me longer than you guys to fix.
many thanks!
don’t suppose you have time to look into how to implement that drag-resize with multiple-selected objects that I couldnt get my head around ?
no worries if not - but you no doubt have a better idea of where to start given knowledge of the framework…
If you like you can just point me in the direction of where the likely place in source would be to make code changes and i’ll do the rest myself.
Yep, I’ve got that working too. I’ll post back here when it’s finished and pushed
1 Like
Oh wow !
You’re a star. Will make a big difference.
This is on develop now - b1ea737
1 Like
Thanks Ed95 and Dstenning…Can’t wait to try these out. Really awesome that you both are still interested in increasing the usability of the GUI editor, despite the fact that the JUCE team said this was deprecated stuff. Thanks!
1 Like
There may be some bugs left. I took 4 components and put them at different y values (vertical placement) and then command clicked them all to highlight them all, then typed in a y value, thinking that all would move to the same y location, but they sort of just moved randomly. I think they are all just sliding the same distance, versus dynamically moving different distances to get the same y value. Maybe I’m expecting the wrong functionality? Width and height seem to be working correctly and as expected, its just x and y that seem to be faulty.
Also, when highlighting multiple elements with varying coordinates, widths, and heights, would be possible to just remove the information in the label associated with those attributes? For instance, if you have two components that are in different coordinates, if you hightailing them both, I would think that the information displaying the coordinates would just display a random character, like ‘?’, or ‘-’, because they aren’t sharing the same… until you manually type one in and force both to move to the same area. Not sure if this would be difficult or not…
Also, when highlighting multiple items, only the first item gets a bold highlight, while the remaining ones get very light highlights… I assume this is probably correct, as the component with the more bold highlight is probably the “main” component in focus… at any rate, I wasn’t sure, so I’m reporting it here.
As Jules said, we keep the GUI editor in the Projucer for legacy reasons but aren’t actively developing new features for it. If someone submits a pull request, like @dstenning did, we’ll review it and perhaps merge it in if it’s a useful feature.
I took 4 components and put them at different y values (vertical placement) and then command clicked them all to highlight them all, then typed in a y value, thinking that all would move to the same y location, but they sort of just moved randomly.
When multiple components are selected, the first one that was selected will have a brighter outline and displays its x, y, width & height properties in the sidebar. Any modifications to these values will be applied to the other selected components, so for example if you subtracted 10 pixels from the x value the other selected components will have 10 pixels subtracted from their x values. This gets tricky when components are relatively positioned, as mentioned earlier, so there may be some odd edge cases but it should for fine for simple situations.
1 Like
Totally understandable, however, I guess I’m confused on what is supposed to happen when changing an x or y coordinate while selecting multiple components. If I do so, weird things happen, whaf is the goal of including the x and y coordinate in the field of multiple selected components? Are they only to be for additions and subtractions to the group through the grouped labels?
Yes it’ll move all the selected components based on the change in position of the first selected component. This is based on what other UI designers like Moqups do.