Great you’re considering this Andrew! BTW - love the look of those dark VCV panels.
Ah, so then the current arrangement (where each module picks its own default light/dark) would no longer be something the user could pick. Is that correct?
I’m not saying that’s a loss or anything, I just want to be clear that the new system effectively forces users to pick between light and dark themes. Is that the intent?
Ok so basically currently we often have a pattern:
Theme → Dark, Light
Default Theme → Dark, Light
in context menu, so the latter could be removed (as inferred from global setting), and the former picks up global setting as default for new instances, but respects user choice if manually selected?
1 Like
I don’t need a global panel setting - It’s a simplifation, that might discourage developers making a multitude of panel themes. (Surge XT, Venom and others). And put pressure on other developers to waste energy making both dark/light versions of their panels.
I prefer to set any panel options locally in each module right-click menu. It lets me chose different looking modules in a patch. If a module has a mostly dark grey and a mostly black graphics, which one is the “dark” panel.
I welcome dark VCV panels.
2 Likes
I’m not sure what you’re talking about.
That seems like a crazy amount of work. It doesn’t seem useful for users to selectively mix light and dark panels. I’ve never seen someone specifically attempt this with their Eurorack collection.
2 Likes
That would suit me better.
Would this feature also affect the appearance in the module browser? I don’t know how many times I missed finding a particular module because it showed the dark version instead of the light version which I prefer.
1 Like
I have 5 “ornament and crime” - they run different MCU’s (and firmware). I turned the panels on the ones that run “sqares and circles”-firmware, to be able to tell them apart from the ones that run “hemisperes”. The panels are black one one side, and aluminium on the other side.
It’s an amount of work to flip the panels, yes.
2 Likes
I think it would be great to have a global menu item “View > Prefer dark panels”, and if a plugin developer wants to give the user the freedom to choose different panel colors for individual module instances, this should be accessible from the module’s right-click menu.
For plugins with more than 2 panel color options, I think the module instances should provide a choice to set the color that will be displayed with “View > Prefer dark panels” = true, and also the color that that will be displayed with “View > Prefer dark panels” = false.
6 Likes
As a user, I think there is clear benefit, so I approve.
As a developer I can see how the proposal would work with my plugin, it wouldn’t be too difficult to integrate.
IMO a method to override for when any rack settings change (like onSampleRateChange) would be much better, is this something you will consider for the next major version?
This seems to be the way a lot of apps are going, with support for dark/light UI, do you intend to have dark/light for the entire app at some point, and will it default to the OS dark/light setting (if it exists)?
My one concern would be that too many of the 3rd party plugins (including commercial ones) would be left behind because the dev doesn’t have the ability to update immediately. So although I think there is clear user benefit, for a user with many 3rd party plugins, the experience might be sub-optimal.
Is the global bool read-only, or could a module (such as my BrightIdea) modify the setting?
Would this require any module developers to change code? In my case, I have a light and dark SVG file, but those are used strictly as the panel background color. I also have light and dark PNG files that are used for rendering the panel while in the browser, but otherwise, my panels are generated procedurally in light or dark themes along with a contrast setting.
Sorry if you answered this here in some way and I missed it.
Edit: Oh yeah, my light and dark SVG files also determine the panel dimensions in addition to the background color.
1 Like
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
For reference, discussion on my theming proposal here: Notes for theme-able SVGs with nanoSvg - Development - VCV Community (vcvrack.com).
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
As user I really would like the “prefer dark” option!
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
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.
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
I agree with this sentiment and have a similar experience.
3 Likes
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