Dark mode for LabVIEW IDE

[TiTou]

When working in LabVIEW in low light conditions, it would be nice to be able to have a quick way to switch to a dark mode, where the default block diagram colour would be a mid-dark-grey.

[marshaul]

I changed my default VI background color to a light-mid-gray some time ago, and this at least keeps my eyeballs from being burned out, but now it means that my VIs have a non-standard appearance, varying with time of original creation rather than anything meaningful.

I really don't see the value in per-VI color schemes in the first place, I have to admit. It seems very odd indeed when I come across a VI with a color scheme radically different from mine, though this rarely happens (which suggests that most folks also don't see the point).

What would have always made more sense is user-configurable themes, where each wire type in every VI is colored according to user preferences, rather than saved per-VI (though per-VI override could be retained in this case for the incredibly rare case where it would be useful). 

The current situation is basically the equivalent of me sharing my C files in .rtf with all my syntax highlighting baked in as colored text. 

The way it should be is like with textual languages: the wires are just raw data, and any colors added are "syntax highlighting" to be accomplished in the user space. 

(Having the background carry color information with it makes even less sense, and is purely a waste of data, except that it is necessitated by the clear error of storing color information within the VI by default). 

[AristosQueue (NI)]

We do not store color information for the diagram in the VI. What we store is the data type of the terminals, which is required for any meaningful save of your work. The colors are defined by the language, not saved per VI.

I see it as borderline absurd to have per-user colors for data type in a graphical programming language. Try coloring all your blue wires as pink and get someone else to read your code. It's equivalent in C++ to adding to the top of your file

#define int std::string

and then writing int x = "abc"; The color is the language in a graphical language, and asking that we have different colors means we aren't using the same language.

(It would get even more confusing with LabVIEW classes where the class author has designed the wire to use specific colors because of their association with other data types. Most classes that represent a reference use refnum cyan. You change the definition of refnums to use something other than cyan, suddenly it isn't clear what those LV classes mean. Similar problems for a class that uses orange for a "infinite decimal point" computation class if you change the color of floating point.)

[marshaul]

OK, I guess it's just backgrounds that are saved within the VI, and wire colors are fixed (I never played with colors more once I learned how colored backgrounds work, because the notion of committing my colored VIs to version control seems quite silly). This still creates an odd and not-particularly-useful situation where VIs can be written and saved in a way that they may be difficult to or impossible to read for other viewers.

Also, I'm not sure how you would construe that by "per-user" I meant "saved in the VI", as that would indeed be absurd. What I meant was "user-end", where colors are assigned to types, backgrounds, and other changeable objects according to the user's preferences and, presumably, saved wherever used preferences are saved. (That I meant this should be fairly obvious by my comparison to syntax highlighting in textual languages.) This would at least enable theming, and would also make a simple "dark mode" toggle trivial to implement. And dark mode, which is the point of this thread, would be extremely nice and is really overdue in 2022.

Are you trying to listen to user suggestions, or are you trying to play "gotcha", anyway?

[AristosQueue (NI)]

> Are you trying to listen to user suggestions, or are you trying to play "gotcha", anyway?

🙂 I've been the primary respondent to the LV Idea Exchange since its inception over a decade ago. I assure you, my goal is to bring as many good user ideas forward into the product as my small team's bandwidth allows. It's my role to flag good ideas, reject bad ones, and -- relevant in this case -- try to encourage deeper discussion on ideas that don't at first blush have a good implementation but are strongly desired for various reasons.

I wasn't equating saved in the VI with per user settings. I'm not sure what I said that made you think that, but let me try again, this time directly addressing the way you restated your position.

> What I meant was "user-end", where colors are assigned to types, backgrounds,

> and other changeable objects according to the user's preferences and, presumably,

> saved wherever used preferences are saved.

Consider two cases.

• First problem: this approach presumes that VIs are always viewed within LabVIEW, and that is not true. From web posts to PowerPoint presentations, there are a wealth of scenarios where VIs are captured as static images... indeed, with the rise of git and various online source code control systems, it's becoming very common for devs to look at each other's code through exported PNGs.
• Second problem: even within LabVIEW, it is extremely common for one developer to need to look over another's shoulder, whether for a simple buddy code review or help debugging. Because I can hack LabVIEW and shift the colors, I know how confused people can be looking at a diagram where the types are all wrong.

In all situations where two developers are looking at the same code, whether live or in screenshots, we need a common language, and per-user settings causes problems. "What if it is relatively easy to set back to the defaults?" Not everyone will do so before doing screenshots, and it'll be a hassle every time one dev shares screen with another dev (increasingly common in pandemic times). The problems inherent in such interplay are substantial enough to say, in my opinion, this is a bad idea.

But let's say readability is not a concern for a sufficient number of users that we decided to go forward. Then we hit the writeability problem that I mentioned earlier.

You see, it isn't just built-in wire types and white diagrams that need an alternate view. I already discussed the custom wires of LV classes. But consider VI icons. Many VI icon have glyphs that incorporate a specific data type color, like string parsing functions using hot pink. Beyond data type, even the black border that most VIs use would need to be a different color to be hosted on a dark-near-black-or-black background, and once you change that, you need to change the interior of the nodes. It isn't as simple as just inverting all the colors for anything other than pure text nodes.

If we open the door to arbitrary color schemes, no one will be able to write VIs that are usable on everyone's diagrams. But, honestly, getting a readable, distinguishable set of colors is actually quite hard, so NI probably wouldn't let users assign every type individually... NI would likely develop a second set of "dark theme" colors and users would pick between the two entire sets. LabVIEW would then render every loaded diagram in whichever color scheme user picks.

Does that mean that users would need to write every VI to have two different icons, one for bright mode and one for dark mode? How many developers will take the time to write an alternate node for the color scheme they don't use? My observation of customers is that very few would do so.

Color is foundational to LabVIEW. We work hard to make LabVIEW usable by people who are colorblind by incorporating pattern into many places, but even in NXG where we could turn off the color entirely and work in the whole product in grayscale, we never got away from all the places where color mattered... and even then, it still was critical that certain things match color. And therein lies the deepest problem with this customization idea.

Overall, I don't think this is a feature LabVIEW can meaningfully implement. I'm not convinced that users recoloring the wires for their own tastes is going to be helpful for most people because so much of the rest of the interface relies on those color associations. I recognize that some customers, including yourself, may disagree with me. I acknowledge that this means LabVIEW is less than ideal for some customers (perhaps to the point of losing some customers). I don't like that, but my current evaluation is that it is better than the proposals for how to have a dark mode.

Having said all that, the idea remains open. Mine is not the only vote that counts, and dark mode continues to intrigue people. It may be that NI will implement it some day. I just don't expect it.

I hope that helps clarify position, and I hope you don't think I'm trolling you or anything. NI (and myself) do welcome the user feedback.

[dadreamer]

---

@-Newton- wrote:

I've found using the "Slide Background" color is a good compromise. It's dark enough, and wires and structures are clearly legible. (Black would be great, but dark gray is much better than bright white.)

You can set it to default for all new VI's following these instructions:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kHfNSAU&l=en-US

You'll also want to set the Application Font to a white'ish color (Control Background is good). This also propagates to new VIs.

---

Then maybe you will find this useful as well. There's a list of LabVIEW.ini tokens, related to the color settings. Some tokens aren't presented in the IDE's GUI, e.g. diagram.primColor, using which you could change the native primitives' color from pale yellow to one of your choice. I know, it's not so good to change that for the common white look of LabVIEW, but it should fit fine for dark-styled looks.

[dadreamer]

In the Test Workflow Roadmap – 2023 Q1 document there's "Updated Fonts & Themes: Dark Mode" work planned for future development ... for TestStand. So we should expect the same feature for LabVIEW, right?

[Bas.v.E]

---

@AristosQueue (NI) wrote:

If we open the door to arbitrary color schemes, no one will be able to write VIs that are usable on everyone's diagrams. But, honestly, getting a readable, distinguishable set of colors is actually quite hard, so NI probably wouldn't let users assign every type individually... NI would likely develop a second set of "dark theme" colors and users would pick between the two entire sets. LabVIEW would then render every loaded diagram in whichever color scheme user picks.

---

I agree on the fact that user should not be allowed to change the type colors on their own. But I love the idea of NI deciding on a dark theme with fixed colors for types and also change the colors of backgrounds where we are not able to change the colors of with the LabVIEW ini like the color picker and the title bar for instance. 

And to get back to the fact that the colors of labVIEW should be recognizable, if there is a large portion of users that want this feature, then it's very important to implement this as soon as possible to get everyone to adjust to the alternative color scheme.

[JohnatanBravo]

It's 2024 and they still haven't figured out how to implement a dark mode...