The committers listed above are authorized under a signed CLA.

• ✅ login: sh4shv4t / name: Shashvat Singh (c05ce4e, 58df91f)

Hi @lgritz, could you please have a look at this PR once? I have added the styling via a --dark command-line argument and will add the Preferences toggle and persistence logic once the styling is approved.

Sorry for the delay. I actually did test this but had mixed results.

I tried both on my personal Mac, and on my work Linux machine. In both cases, I saw minimal change, but maybe that's because I run in dark mode? Is it possible that Qt behavior is that the OS display choices explicitly choosing dark mode impose a dark palette and so this makes a visible change only if your OS and user choices are light mode? Or is it possible that it only makes a difference on certain window managers, or on MS Windows (which I couldn't test)?

Can you please post images showing the before and after appearance of iv that you expect with these changes?

It's 100% ok with me if all this effectively does is make it look dark when in light OS mode, but on effect if you've already selected dark mode and imposed a dark palette across the board. That still would be an acceptable patch.

My bigger concern, though, was that I -- totally coincidentally, I would not have consciously thought to try this -- tested it by displaying an image that happened to have an alpha channel and was transparent in some places, and this patch (versus main) definitely led to a different appearance in the "transparent" pixels. It must somehow change the background color? I would like for you to test this and track it down, we wouldn't this to inadvertently change/lighten the background pixel color for pixels with non-1.0 opacity.

@lgritz Thanks for the review!

Dark mode visibility: You're right in saying that if your OS is already in dark mode, the effect is minimal and that is consistent with Windows 11 too as per my tests. I believe this is because Qt inherits the system palette.

Transparent pixel background: I investigated this and believe I've found the root cause which was that the dark QPalette was applied in main() via app.setPalette() before ImageViewer was constructed. But the ImageViewer constructor then called QApplication::setPalette(m_palette) with a different palette (either QPalette(Qt::darkGray) or default), partially overwriting it. This race between two competing palettes could cause inconsistent widget backgrounds, which would be visible behind transparent pixels in the QOpenGLWidget.
The actual OpenGL clear color for transparent regions (glClearColor(0.05, 0.05, 0.05, 1.0) in ivgl.cpp) is hardcoded and completely independent of QPalette, so the image compositing itself isn't affected but the widget background leaking through at the edges could change appearance.

Fix: I've reworked the implementation to integrate --dark with the existing darkPalette preference system inside ImageViewer. The palette is now set up in a single place (the constructor), eliminating the conflict. I also upgraded the existing dark palette from the minimal QPalette(Qt::darkGray) to use the Fusion style with a proper dark color scheme, so the Preferences checkbox now produces the same improved result.

Please have a look let me know if this approach is okay and if these changes are okay to be merged. Also would you still like a before and after for Windows 11?

@sh4shv4t I would like to know how you want me to proceed here:

I'm not sure if you've seen discussion on the openimageio Slack channel, but another developer has recently let us know (not only after you did the work for this PR, but in fact even since the last comment on this ticket) that he is working on an overhaul of iv that switches entirely from Qt to imgui (providing a much lighter-weight dependency -- Qt is just way more than we need for this little app, out of proportion to the size and difficulty of building it). We expect that perhaps within days, we will receive that PR. I'm not sure how much revision it will need or how soon it will be merged, but I'm assuming that it will eventually be merged and we'll drop Qt.

Needless to say, a switch to a different GUI toolkit would make this PR unnecessary and surely would overwrite any changes. I feel bad about that for you, since you already put the work into this. But sometimes that happens, two PRs come in and one make the other unnecessary. In this case, I did not know the other was coming when you embarked on this work, or I would have warned you not to spend time on it.

I would say that is is up to you what we should do next. As I see it, there are basically two choices:

1. We can merge this (after one last check that it appears to do the right thing), so that you can feel like we did merge your work. There's no telling how long it will be before it's overwritten and essentially removed -- maybe days, maybe weeks?
2. We can wait and let this PR sit to see if indeed the other PR comes as soon as we think and looks good -- we presume it will, but there's always a chance that it needs so much work that it will be quite a while before we switch to imgui, and do want to merge your PR.

I'm kind of inclined to leave it up to you. I don't have a good guess for how you're going to feel about either abandoning this PR, or about merging only to have it almost immediately overwritten. Either way, this circumstance wasn't your fault, and we are no less appreciative of the PR than if it had been merged and not modified for 10 years.

The failures of the Mac CI tests appear to be unrelated to this PR.