New WYSIWYG GUI Editor on Steroids with FlexBox and Grid Features

Feature Requests
1

I personally think the JUCE WYSIWYG editor is the best thing since sliced bread and don’t understand why it has been deprecated instead of being brought up to date with the addition of FlexBox and Grid features.
I cannot imagine being able to develop the very complex development interfaces I find necessary to do my vocal processing code. The ability to open a prior interface and copy and paste the controls, move them around etc. I find invaluable.
Indeed, I wonder why people seem to almost apologize for using it when not using it strikes me as a form of masochism.
I must be missing something.
Anyway, I for one would like to see the WYSIWYG JUCE editor updated and pulled out of the deprecated status.

2

Yes please! Or implement a stylesheet based system with live update. So i don’t need to stop, recompile and start my application each time i moved a component a pixel to the right.
Now we need c++ programmers to do the work that Front end developers should be doing. c++ programmers don’t grow on trees, front-end developers do apparently.

1 Like
3

Search the forum for @daniel’s GUI Magic project

2 Likes
4

Thanks!

Will search it out.

Lacy

5

Thanks for mentioning PluginGuiMagic, let me save you the search and link a few places:

Announcment thread on the forum:

Here is a Repository with example projects how it can be used:

And finally the repository containing the module, that’s all you need to add to your project:

If you have any question feel free to ask here, raise github issues or find me sometimes on the discord server

1 Like
6

Daniel,

Looks very interesting. Looking forward to

viewing the YouTube videos and testing it out

over the coming week or two.

My C++ is still quite rough around the edges

so it takes me a while to assimilate new things.

My eyes cross after about 30 minutes of new

stuff like this :wink:

Thanks!

Lacy

7

How does the old WYSIWYG editor work? Does it use specific coordinates or does it use relative bounds to the parent component? I only ask because I’m surprised to hear that people use it because I would have thought it would cause all kinds of problems with things like resizable windows?

8

I was surprised to learn that it actually creates a resized() method, so yes it is some kind of proportionally scaling. I didn’t check if it uses plain maths or setBoundsRelative()

It’s been ages that I used it though…

1 Like
9

I did my best to hide the dirty bits, but sure, to add those visualisers and the parameters to control to, a little bit of C++ is involved… it needs to know what to visualise :wink:

10

I think this would make a good question for the annual survey. I feel like I’m missing a “downvote” option here, because I would rather see the JUCE team concentrate on core functionality over something like this. It would be good to get a proper view as to how many people with paid licenses actually want to see this kind of thing implemented, because I can swallow my personal dislike of such a feature if there are a majority of people who are paying for JUCE that want to see it implemented.

This is something that I could get behind, but the complexity of implementing things like proper responsive layouts (hiding/showing controls based on window size) seems like it might be a huge undertaking, and so I still err towards the side of preferring core functionality over this.

2 Likes
11

I think there is no need to downvote. As long as your priorities are voted higher, there should be no problem.

BTW. PluginGuiMagic allows responsive layouts, the style classes can be conditional on a max or min width or hight, that way they can show or hide things. Thanks to FlexBox the layout will adapt accordingly.
You can even switch from flexbox to a tabbed component. I started toying in the EqualizerExample, but need to make a better design, then I can provide a tutorial video.

12

I was being slightly facetious, mostly because all my priorities are way smaller tasks but with significantly less votes :joy:

Really my issue is that you’ve already provided a system should people want that functionality by releasing PluginGuiMagic. I’d rather see the people who need to use WYSIWYG GUI editors use that and the JUCE team deal with things that benefit a broader base. It’s just difficult to gauge if I’m holding a minority view or not. :slight_smile:

1 Like
13

Oh, I would absolutely love that, believe me :slight_smile:

14

Yes please! Or implement a stylesheet based system with live update. So i don’t need to stop, recompile and start my application each time i moved a component a pixel to the right.

This already exists in a way - LiveBuild allows you to do this much more easily than recompiling completely & writing code is no harder than using style sheets once you get the hang of it. I use LiveBuild when planning and defining what each GUI section will look like.

You may still prefer to use @daniel’s PluginGuiMagic; from what I have seen, it is quite nice.

I’d rather see the people who need to use WYSIWYG GUI editors use that and the JUCE team deal with things that benefit a broader base.

I completely agree with this.

15

Yes, that is editable at runtime as well. Only once finished a recompile is necessary to bake the changes in the BinaryResources. While editing it is held persistent in the plugin state (APVTS.state)