I wrote a module to turn the Ignition Designer dark.
It is for 8.3, it is free, and it goes on the gateway once, so every Designer that connects can toggle dark mode on or off. This setting is saved locally on each developer’s computer.
@justinedwards.jle already covers 8.1 with Dark Mode for the Designer on the Exchange, so if you are on 8.1 go get that one instead. Mine is a module rather than a project script, and it works differently underneath. Rather than painting components one class at a time, it swaps the look and feel out for FlatLaf and rewrites Ignition's own colour tokens, so most of the Designer comes out dark without me having to go find it first.
This module is still work-in-progress and I built the whole thing on a Mac, so it might not work properly on another OS. If you find bugs let me know.
Feel free to play around with it:
Download designer-dark-mode.modl from the latest release.
Install the module in the gateway UI
Accept the module's certificate.
Turn it on with Tools → Dark Mode (menu bar).
Disclaimer for Vision developers:
If you add this module to your designer and work with Vision, this might (will?) cause a mess of changes that will give you or someone else a bad time later.
Just a question that will probably arise, does this setting get saved and loaded across designer rstarts? And is it saved per-gateway, per-project, or for all?
I know this would help one side of our office where for some reason the lights are dimmed so low it's like a nursery...
Currently, it is a persistent setting on the developer's computer. So, not a gateway or project wide setting. To me this sounds like the most logical option. What do you think?
Besides the eyestrain worries literally visible in the hero screenshot (black text on dark gray background) that you're going to have a hard/impossible time working around, the much more serious warning you should throw on this is that it is fundamentally incompatible with Vision.
If you start loading this in your designer and working with Vision resources, you will cause a mess of changes that will give you or someone else a bad time later.
Dropping in FlatLaf is easy; dropping in FlatLaf without corrupting Vision is ~impossible.
Thanks for the heads up, Paul. I will add a disclaimer for the Vision issues. Personally, I never really use Vision. Do you think there will be more issues besides Vision?
That's just wrong. People like me (presbyopia, like many older folks) are greatly helped with focusing depth of field with light backgrounds. If it isn't opt-in per user, it isn't appropriate.
Well the wording is a bit unclear but it is an opt-in for each developer. I meant by this sentence that the option to turn it on or off goes to every designer. Then this setting is saved on the computer of each developer.
I have an 8.3 compatible version that's currently in reviewpublished on The Exchange that fixes the following issues:
• Perspective binding icon and add object member icon behaviors
• Security panel text not readable
• Removes system.gui calls that require the Vision module to be installed
I'm the exact opposite. I use Perspective occasionally when I need to develop a form for the data crunchers and office types, but most of my work revolves around the actual trenches, so naturally, I use Vision. My patch works perfectly for this because it doesn't hack the look and feel. Instead, it has a target list of valid containers whose internal components are allowed to be painted in the dark theme. Vision stuff lives in a JRootPane, so that is simply excluded from the list to ensure nothing inside somebody's project is affected by the patch.
I simply replace the DefaultTreeCellRenderer with one that swaps out the HTML tags, and when the user switches back to light mode, I just put the original renderer back in place.
# IA uses html to render bean properties, and one of the colors they use is black. This renderer switches the black letters to white,
# ...so they will show up against a black background
class DarkModeTreeCellRenderer(DefaultTreeCellRenderer):
def __init__(self, originalRenderer):
self.originalRenderer = originalRenderer
def getTreeCellRendererComponent(self, tree, value, selected, expanded, leaf, row, hasFocus):
component = self.originalRenderer.getTreeCellRendererComponent(tree, value, selected, expanded, leaf, row, hasFocus)
darkModeText = component.text.replace("<html><span style='color: black", "<html><span style='color: white")
component.text = darkModeText
return component
I don't use it all the time, but I find it extremely helpful when working on two projects at the same time, like I've had to do while working on 8.3 upgrades. Somehow, having the designers colored differently helps keep my brain from mixing the two up and making mistakes.
Sorry for the slow reply, I was on paternity leave.
Thank you for trying it. I just created a new release tackling the problems highlighted in this thread. You can find it on our company website or on github.
@paul-griffith, you were correct about Vision and I could reproduce the issue. Now the module refuses to go to dark mode when Vision is open or you navigate to it. I also adjusted the black property names so it is less of an eye strain. Let me know what you think.
@justinedwards.jle, nice that you also released an update for your dark mode resource on the exchange for 8.3. It might be the better option at this point for people using Vision.
@MUNIYANDI_D It should work on Windows, but I lack a Windows device to test it properly. So you might have found a real issue. Can you test it out with this new release?
Two things you can do to help me narrow it down:
Check on the gateway under Platform > System > Modules. Do you see the modules in this list? And if, so it it running properly? Let me know if you see errors here.
Also, check whether %USERPROFILE%\.ignition\designer-dark-mode.log exists on your device running the Designer. If it does, past it here (or DM it if it hold confidential info).
Still just surprised it's not an official feature, especially since the "original" dark mode resource was quite a while ago and there is clearly a lot of interest in it.
Cool project though, I like the idea of implementing it as a module in the gateway. The 8.1 resource always felt a bit "hacky" to me and so I never ended up using it long-term.
