"Prefer dark panels" proposal

Development
21

My upcoming plugin supports Light, Dark, and High Contrast themes on per-module basis:

pachde1/docs/index.md at main · Paul-Dempsey/pachde1 · GitHub (drill down to see each module and their themes).

The proposed scheme is nice enough for developers using panel SVGs, although it does mean a developer must maintain parallel SVGs, which can be a hassle.

In addition to the panel creation help for panel SVGs, there is a need to be able to query what variety has been chosen. When I was implementing theming, I initially considered following the Rack setting, but I found that the Rack modes aren’t initialized at the point when I needed to query it (it was always Light, even when I’d chosen Dark).

Only one of my panels uses an SVG, and even then, most of the UI is procedural.

Theming doesn’t apply just to panels. It needs to apply to widgets as well: knobs, screws, ports – all the things, so you’d need a way to support that as well.

If there is a querying mechanism for the Rack preference, I’d offer a per-module option on whether to follow Rack’s theme or not, defaulted to following Rack, but offering the ability to override.

Of course, this also implies notification of when the Rack theme is changed (possibly per-widget like other notifications).

Of interest to the discussion: I’m working on a way to theme Rack SVGs in-place based on a style sheet (in JSON), so you only need to maintain one SVG, and can modify the SVG on-the-fly when desired.

The proposal doc is here: pachde1/dev-notes/svg-theme.md at main · Paul-Dempsey/pachde1 · GitHub. Note that this can be applied to any widget where you know how to reach it’s NSVGimage, including your panel widget.

I’m almost finished with the MVP implementation. It’s sort of working, but few issues left to run down. I was surprised how well it worked on the very first run! There are some features to add to make it easier to use, such as defining an svg provider interface you can dynamic_cast a widget to and reach all it’s svgs for modification. There’s likely another helper or two to make it as simple to use as possible, including a method to add a complete Theme selection menu for the module.

If you implement an api to query and respond to theme changes, I’d add support for that.

2 Likes
22

For reference, discussion on my theming proposal here: Notes for theme-able SVGs with nanoSvg - Development - VCV Community (vcvrack.com).

23

These were the same questions I asked up thread basically. The answers came to

1: rack has a global variable you can check in step if you don’t want to be svg based.

2: with surge at least I would add a new display state which is the probably default called “follow rack wide setting” and then leave all the override mechanisms I have in place for single modules and so on.

3: With air windows and bacon plugs I would just follow the variable but they have far simpler skinning mechanisms

1 Like
24

As user I really would like the “prefer dark” option!

25

In my own extensive Eurorack hardware system, I intentionally alternate light and dark theme modules as it makes it much easier to see the modularity and to easily see where one module ends and another begins.

1 Like
26

I’ll attempt to illustrate with an example.

Take two modules that both have a light and dark mode. To make it concrete, two real world examples are:

  • Analyzer, by Bogaudio. It defaults to “Light”.
  • Plateau, by Valley, which defaults to “Dark”.

Currently, if you add these to a patch with no further actions, Analyzer is light, and Plateau is dark.

Under the new regime, if preferDarkPanels is false, then both will be light. If preferDarkPanels is true, then both will be dark. Correct so far?

Of course, if for some reason the user is accustomed to the previous default colors, they can twiddle each of the modules back to their default values. So no option is being forcibly removed, I realize.

What I’m noting is that there is no “accept default” value for preferDarkPanels. If the default value is “false”, then in every new and existing patch, all of the dark panels that have a light theme will suddenly become light. (e.g., all the Plateau’s become light). Again, am I reading that correctly?

One would suspect this will lead to some user confusion, though perhaps not enough to matter to you. Your call! Just noting that this is a visible behavior change for existing patches. And that for experienced users who think of Plateau as always being “dark” and Analyzer being “light”, this will be a surprise.

27

Additionally, I’ll note that in my career in software, about half the time that I made a boolean field for other team’s software to read, about half the time I would later wish I’d made it an enumeration instead, because I needed to add a third value.

I’ll gently suggest that the future may bring other visual themes into vogue (“no blue”, “all grey”, “maximal contrast”), and so you might profitably choose to make this an enum instead.

4 Likes
28

I agree with this sentiment and have a similar experience.

3 Likes
29

I think there is not changes in user matters, it not force to you to select a theme, it only will affect for modules tha follow the guidelines to “prefer dark modules”, it will not affect the modules that dont have alternative faceplates, for instances there is not a dark theme for vult

30

In contrast to my modules, Vult modules look pretty dark :sunglasses:

1 Like
31

I tend to agree. Any module that has theming will probable have their own overrides. It’s not going to have many bad effects.

3 Likes
32

That is what I would expect too.

2 Likes
33

I like the idea and hope it will be implemented. In Geodesics and Impromptu, we would likely add an option to “follow Rack global theme”, which would be the default when new modules are added to the patch. We would still allow the user to manually set the theme of specific modules if wanted though. For example, I’ve always thought this might have some use, to quickly spot where C4 is located:

image
image1218×399 78 KB

I also think the word “prefer” in “Prefer dark panels” neatly solves the problem of the option not being perfectly applicable to all plugins, like MindMeld and Alright Devices for example, who have only one color theme that differs between the two (MindMeld only black and Alright Devices only light).

10 Likes
34

Agree with having a global setting as a primary preference with the ability to override per module when desired.

2 Likes
35

Expanding on this idea of an enum rather than a bool @Vortico

I could easily see concepts like “high contrast” (for visually impaired but non blind users) being something plugin support. Having a high bit you could set on the variable would allow a toggle like this, and already has support in the menu set.

1 Like
36

Why not about “Prefer dark panels”? The idea is interesting. :ok_hand:

37

How about automatically switching based on time of day, now we’re in Apple land!

2 Likes
38

Don’t worry, within 30 minutes of the feature being released, someone will create a module that drives the theme setting from a CV input. :slight_smile:

9 Likes
39

LOL.

Joking asside, I love the idea of the prefer dark input flag, please go ahead with it Andrew.

And also I’d like to see the Vult modules in even darker when you select this! Anyone read The Hitchhiker’s Guide To The Galaxy? Here is a description of the interior of Disaster Area’s (a heavy metal band) auto-pilot space ship that crashed into a nearby sun at the climax of their concert:

“Marvin was able to touch the surface of the ship and open up an entry hatchway, and the interior of the ship was completely black. There were black controls labelled in black, on a black background, with a little light that lit up black, which made it difficult to control the ship. The ceiling and walls of the swaying cabin were also black, as well as the seats, control panel, the instruments and the little screws that held them in place. The thin tufted nylon floor covering was black, and when a corner of the foam underlay was lifted up that was also discovered to be was black.”

2 Likes
40

haha

The benefits of open software architecture!