Additional style overrides

[wellis]

Feature description

We would like to be able to override more style aspects. This issue will collect together and prioritise these overrides.

All Widget Types

• Show/Hide

  Label

• Text
• Parameter Text Display

  Component

• Background Colour
• Background Image

  Rectangle

• Corner Size
• Fill Colour
• Outline Thickness
• Outline Colour

  Image

• Filename
• Opacity

  Slider

• Popup Enabled
• Velocity Based Mode
• Rotary Mode
• Inc/Dec Buttons Mode

[bcsharc]

Something I'd like to add here is a 'Cap Colour' option for rotaries. This would be a static image which is loaded behind a rotary slider and can have it's colour defined. Any transparency in the overlaid knob animation would then expose this colour.

This would give us the ability to colour code caps / surrounds / indicators on rotary image sliders freely without needing multiple variations of the animated graphic.

[wellis]

Would it be worth considering SVG paths for this, as we'll then be able to fill them with a colour on the fly (like I'm doing with the icons in the config mgr treeview)?

[bcsharc]

Absolutely. What I'm suggesting is an additional single frame monochrome png as the source image for the 'cap', so if an SVG path is generated from that which we can control the colour of then it should hopefully work.

The main thing is getting this element to work as part of the rotary slider LnF - kind of like the background image on the horizontal & vertical sliders except with the option to change colour.

[bcsharc]

We could even have it inherit from rotarysliderfillcolourid since this would only be used on image sliders.

[wellis]

I don't think we're can generate an SVG from a PNG in JUCE, but we can create a JUCE path from an SVG we create outside of JUCE, as long as it's fairly simple.

[bcsharc]

How about the Drawable::createFromImageFile then - http://www.juce.com/api/classDrawable.html#a71c90179ca2a582ef0814c983be41dc9?

[bcsharc]

It will definitely be simple enough for the SVG option though. Most of the time it would just be a circle ...sometimes with an area masked out.

[wellis]

Will have to have a play with that and see how it works out.

[wellis]

Colour overrides are now supported for:

• Slider
• TextButton
• Label
• Component

I haven't done TabbedComponent or ComboBox, as they probably won't be used that much in generic templates and the colour setup is a bit more complex for those.

[cwmod]

from a user's point of view, I see three main points: 1) good oversight. 2) fast accessibility. 3) in editing the VST, quick options to choose the wanted style. 1) a 64 control panel is already rather complex just using knobs, even with different layout & colours. 'real' synth panels have traditionally faders, knobs, buttons. -Maybe I missed something, but I didn't see faders as style overrides in the recent release - would absolutely makes sense to have them. Even if they would be quite small, but I could see at once where my envelopes or mixer gains are. -buttons: I would prefer buttons before knobs for switching. or -comboboxes for more complex modules like osc waves, tempo dividers and such. -if possible, some 'line widgets' which indicate groups of controls / separate them from others would be good 2)-imho comboboxes have much faster accessibility than knobs for multi-selections. -same goes for buttons for switches. designated text boxes to describe the various button states would be good (I know, shortage of space is a matter) 3)in 0.4 there are a lot of knobs at choice, which makes it a bit cumbersome to choose one. maybe some tree hierarchy orientated navigation would be better?

[wellis]

Almost all of that is already available in the layout XML and we will be selectively adding features into the style overrides functionality. We are being cautious about adding too much though, as we don't want it to become overwhelming, like similar GUI editing tools.

We want to steer users towards using the XML for more complex layouts, as that gives total flexibility around positioning/style etc. It's much easier than you might think (for most things anyway). Check out one of the simpler .layout (e.g. the 8x2) files to see what's involved. If you use an XML editor like Eclipse or Visual Studio, you'll get text auto-complete functionality, as we've created a supporting XML schema.

Having said that, the widget template override idea I've mentioned might well cater for a number of the scenarios you've suggested, especially being able to switch in a combobox, fader or button.

I'll have a think about point 3), as we could add some form of categorisation/grouping of LnFs, allowing for a more hierarchical navigation. I hadn't expected Simon to create so many great styles :)

[wellis]

P.S. for reference the currently available widgets in the XML are as follows:

component - a container widget for other widgets slider - either encoder or slider (parameter-aware) label - text field (parameter-aware) textbutton - standard image/text button (parameter-aware) tabbedcomponent - containing multiple tabs, each hosting a component (parameter-aware) combobox - standard drop-down box (parameter-aware) rectangle - drawn rectangle image - image renderer (supports mostly compressed image formats, e.g. png and jpg)