I've got dark mode on my phone, dark theme in windows, my terminal windows are all dark, I have chrome extensions, and scripts to force websites that refuse to adapt and evolve to use custom CSS to make them dark...

I spend my entire workday in front of an array of monitors and have taken every step possible to reduce the amount of blinding white screaming hot photons that would otherwise come blasting into my eye sockets, and then there is Winbox.. Which I have to spend a good portion of my day working with, which I have no ability to tame down. It's just screaming hot bright blinding white light at all times.

Is it really too much to ask that some time be taken to implement an alternative color scheme for this application?

You have a user, who buys, who uses, and deploys tons of your products, in actual physical pain because of the use of Winbox.

Blinding screaming hot white light-induced headaches are not a requested nor desired feature.

Please.

Do like me, put eyeglasses with blu light filtering on that.
I see everything brown but that is ok !

USE CLI ;-)

Do like me, put eyeglasses with blu light filtering on that.
I see everything brown but that is ok !

More like welding goggles...

This is kinda what it feels like to open up winbox...

Ah yes, the only problem left to be resolved in the MikroTik world: a dark mode for WinBox.
As a side note, I have all my monitors set at around 120cd/m2, which is a reasonable value for most home/office environments, no "screaming white light" here.

Yeah, seriously this is LAST thing Mikrotik should be working on at the moment.
Just look around, there are serious bugs, memory leaks, ROS 7 issues, new wireless drivers problems...

Yes, because changing a color would take an entire team of devs several months. /s
What does WinBox background color have to do with ROS other bugs is beyond me.

or at least option to reverse colors of WinBox :D

Please Mikrotik,

do NOT spent your time on something like Darkmode, it is not neccesary !
Focus on fixing bugs in ROS and prepare for ROS7...

There is a way - altho not a straightforward one.
Using Linux and Wine, you can force a "theme" for a Wine prefix. You then run Winbox inside that prefix. The theme can override any colors you want.

This is an example of forcing a dark theme for Winbox:


It's not perfect, but it works. If you are running Windows... sorry, no good news for you there.

There is a way - altho not a straightforward one.
Using Linux and Wine, you can force a "theme" for a Wine prefix. You then run Winbox inside that prefix. The theme can override any colors you want.

This is an example of forcing a dark theme for Winbox:


It's not perfect, but it works. If you are running Windows... sorry, no good news for you there.

I am stuck within the Corporate Windows ecosystem.. But I do run the Linux subsystem just so I can have a proper terminal when connecting to all the cloud services I manage...
Installing an xserver might just be worth it.

Thank you very much for this option.

Based on the above wine findings, I have tried to do the same on windows and it sort-of works, but it's not as good.
I have injected DLL into winbox process that replaces GetSysColor API and instead of returning default windows colors, it returns colors from wine dark theme.
This seems to be OK for most elements, but some are still drawn in gray, meaning it's either system control or Winbox gets the color from somewhere else.
For Mikrotik developers: Doing the same in your own code is as simple as making GetSysColor function in your code, so it doesn't get imported from windows DLL and then supplying color values from INI file or some other source. This way you will not have to make any changes to your existing code, this is basically equal to my DLL injection method. (And to call original function, just use LoadLibrary + GetProcAddress).
Based on my screenshot, this seems to do the job for about 80% of GUI elements, rest may be using hardcoded colors or they use windows GUI controls that have fixed colors (these will be probably hardest to change on per-process basis - I think this applies to menus and toolbars, they can be owner-drawn but that requires some extra code to do so).