Some plugins' icons disappear when going from light to dark mode

Mark Olson

IMO most of the available evidence points to a very subtle bug in Notepad++, and so far nothing (including my own staring at how my icon initialization code compares to the corresponding code in other plugins like this code here) has particularly dissuaded me from this perspective.

FWIW, most of the Notepad++ code manipulating icons on the toolbar seems to be in the ToolBar::reset(bool create) method. I’ve tried to step through it in the debugger, but I just don’t have the patience to figure out what the hell is going on. Maybe I’ll take another crack at it tomorrow and figure something out.

Snabel42

@Mark-Olson I’m not sure if this is related, at all … but when switching between light and dark mode while the style configurator is open. It appears as if Notepad++ gets a little confused about what theme is actually active.

After closing and opening NPP again, opening the Style configurator in light mode shows the darkmode theme selected.

It also seems like the change to move the ‘default’ theme to the top gets somewhat reversed and the Global Override is back on top.

I’m trying to nail down steps to reproduce, but it’s all a bit strange.

PeterJones

@Snabel42 said in Some plugins' icons disappear when going from light to dark mode:

It also seems like the change to move the ‘default’ theme to the top gets somewhat reversed and the Global Override is back on top.

There is no confusion on Notepad++'s end. The order of the styles in the Global Styles list is 100% dependent on the XML file for your stylers.xml or selected themes\*.xml – look in the <GlobalStyles> section in the XML, and you’ll see that in whichever mode it’s “right”, the <WidgetStyle name="Default Style" ... will be the first entry in the section, and in the mode that it’s" wrong", the <WidgetStyle name="Global override" will be first. If you don’t like the order, change it and restart Notepad++.

(I just looked at the DarkModeDefault,xml and other themes\ in the portable of 8.7.5-RC1, and it’s got the wrong order compared to stylers.model.xml – apparently, when the order was “fixed”, it was only for the default stylers, not for any of the themes. My ConfigUpdater.py script, shared in Config Files Need Updating, Too, does fix the order in all the themes to match the order in stylers.model.xml, so it’s yet another reason to run that script using the PythonScript plugin.)

Snabel42

@Snabel42 if I switch to dark mode,then open the style configurator, NPP will select the Default (stylers.xml) theme. After closing and reopening NPP, then opening style configurator while still in Dark mode, NPP will select the DareModeDefault. If not a bug, at least a deficiency?

I believe the theme DarkModeDefault deserves to be aligned with the Default theme when it comes to Default Style vs Global Override. DarkModeDefault is not just a user-chosen theme but an actual “mode”. But I suppose that’s a feature request then?

PeterJones

@Snabel42 said in Some plugins' icons disappear when going from light to dark mode:

If not a bug, at least a deficiency?

My reply wasn’t about that section. It was only about the section you quoted. But, since you ask…

if I switch to dark mode,then open the style configurator, NPP will select the Default (stylers.xml) theme.

~~I cannot reproduce.~~ if i start in light mode with stylers.xml, then change to Dark theme, I close the Preferences dialog and open the Style Configurator, and it’s immediately on DarkModeDefault. Thus, working exactlty as I’d expect, and not as you describe.

I believe the theme DarkModeDefault deserves to be aligned with the Default theme when it comes to Default Style vs Global Override. DarkModeDefault is not just a user-chosen theme but an actual “mode”. But I suppose that’s a feature request then?

It should be a feature request, yes. But note that because Notepad++ doesn’t overwrite your existing AppData themes when you upgrade, even if the ones in the installer were updated to match the order in the stylers.model.xml, you wouldn’t notice when you upgrade, because it will still see your old copy. (This is intentional, because the installer doesn’t know if you’ve customized or not, and doesn’t want to risk deleting your customizations.)

PeterJones

@PeterJones said in Some plugins' icons disappear when going from light to dark mode:

~~I cannot reproduce.~~ if i start in light mode with stylers.xml, then change to Dark theme, I close the Preferences dialog and open the Style Configurator, and it’s immediately on DarkModeDefault. Thus, working exactlty as I’d expect, and not as you describe.

Update (and hence the strikeout): The first time I open Style Configurator after changing to Dark Mode, it correctly claims the DarkModeDefault is active, as I said above. But then after making my post, I went back and was going to switch back to my normal Light Mode, but accidentally clicked Style Configurator instead of Preferences… and when I did, I saw that it was now saying Default (stylers.xml), even though it was still obviously DarkModeDefault in reality. So I have now confirmed the bug. I would recommend that you put in a bug report for that one, but make it clear in the Steps to Reproduce that it might be different on the first time and second time opening the Style Configurator.

Snabel42

@PeterJones I’m glad you tried some more and managed to see that something wasn’t quite right.
I’ve known there’s an issue for quite some time, but I couldn’t quite get the steps to reproduce it down.

I thought I’d mention it here to try to crow source it a bit or at least shame myself into spending some time on it. I’ll try to reduce it to at least one consistent set of steps and then report it

@Mark-Olson sorry for the thread hijacking, assuming my issue is unrelated to yours

rdipardo

@Mark-Olson said in Some plugins' icons disappear when going from light to dark mode:

IMO most of the available evidence points to a very subtle bug in Notepad++, and so far nothing (including my own staring at how my icon initialization code compares to the corresponding code in other plugins like this code here) has particularly dissuaded me from this perspective.

Only thing I can think of trying is to recreate your *.ico files like this:

@echo off
@rem ~ 31K (all dims)
@rem ~ 5K  (32,16 only)
magick %1.png -define icon:auto-resize=256,128,96,64,48,32,16 %1.ico

As you probably know already, the *.ico resources are what gets loaded if any of the “Fluent UI” styles has been selected in Preferences > General, in light or dark mode. The BMP files are just legacy baggage for users who prefer to Win2K look-and-feel of the “standard” icon style.

The crucial difference is that BMP icons are statically sized; the ICOs are “fluent”, i.e., can be scaled up, since an ICO is basically an archive of multiple, varying-sized images.

Is it possible your existing *.ico resources don’t provide one of the dimensions which the fluent UI code is expecting, making them disappear at certain scales … ?

Mark Olson

@rdipardo

Thank you so much for suggesting that I resize my icons and bitmaps.🎉 Your depth and breadth of knowledge continues to impress. I don’t know why I didn’t try doing this sooner! This doesn’t seem to have completely addressed the issue, because now it seems that the icons sometimes disappear when going from light to dark or dark to light, and I have no idea why it’s inconsistent now.

Anyone who wants to look at my first crack at addressing this issue can download my most recent commit, JsonTools v8.3.1.1. After reading up on how ImageMagick handles geometry, I was able to update my batch file to get my icons and bitmaps to 32x32 and 16x16 respectively.

rdipardo

I said in Some plugins' icons disappear when going from light to dark mode:

BMP icons are statically sized; the ICOs are “fluent”, i.e., can be scaled up […]

This is mostly correct, but I should have mentioned that toolbar BMPs actually can simulate a kind of “DPI awareness”, provided your plugin interface can access the GDI device capabilities API. See, for example, how ComparePlus goes about sizing its icons. There’s also a .NET example in my experimental template project.

If that’s too much trouble, just re-dimension your bitmaps to make sure they can scale up without blurring, then load them at 24x24 pixels, since that’s what the graphics device will normally choose for conventional screens using 96 DPI.