Trying to create a DPI-aware icon set

I've just bought a Surface Pro to replace my elderly laptop. When I ported my Opus setup to it, the icons in one of my docks look far too small in the Surface's default 200% scaling so I'm trying to create a new .dis file to hold multiple sizes. For reference, the bar currently just uses .png files from the My Pictures directory, rather than icons from an existing .dis file.

Based on the information here, I've created a test XML file:

<?xml version="1.0" encoding="utf-8"?>
<iconset name="NJM_AppsBarIcons">
	<display_name>NJM AppsBar Icon Set v1</display_name>
	<copyright>(c) 2015-2017 It Wasn't Me, Guv</copyright>
	<artist>The Internet</artist>
	<set size="large" width="64" height="64" filename="internet-64.png">
	    <dpi base="100">
		   <scale factor="100" filename="internet-64.png" width="64" height="64" no_scale_min="0" no_scale_max="125" />
		   <scale factor="200" filename="internet-128.png" width="128" height="128" no_scale_min="126" no_scale_max="-1" />
		</dpi>
		<icon name="Internet" row="1" col="1" />
	</set>	
</iconset>

I think I must have done something wrong because the icons don't seem to change size when I change the scale. I've tried making the scale change before the icon change and vice versa, and restarting Opus before and after the changes in both cases but whatever size the icon is when it's first loaded, it stays that size.

Is there something wrong in my XML? (Note that there are only "large" icons because I have that checkbox ticked in the actual toolbar. I assume this isn't an issue.)

Ignore me. I think it's working as it should, but I'm too stupid to understand what I actually want it to do. Further poking will be done.

I changed the two images so that they look completely different (i.e. one's 64x64 and silver, the other's 128x128 and blue). On my desktop (100% scaling) I see the silver 64x64 icon in both the toolbar and in Preferences (where Opus reports that the icon set contains 1 large 64x64 icon), while on my Surface (200% scaling), it's the blue 128x128 icon and Opus says the set contains 1 large 128x128 icon: I assume that this is as expected, given the scaling. I'm expecting to see the silver one at 100% scaling and the blue one at 200%. I'm expecting that when I change the scaling, the other colour icon should show up in the toolbar, and perhaps Preferences should report the other dimensions, but I'm seeing neither of these changes.

Another interesting thing: I'm using another home-made icon set which definitely doesn't have DPI-awareness. On the Surface, its small and large icons are reported as 44 and 64 pixels, while on the desktop they're 22 and 32. These reported sizes do not change when I close Opus, change the scaling and the reopen it.

Edit: it looks like it all needs me to sign out and back into Windows to see the change reported in Preferences and for the other icon to be loaded. I now assume it's not supposed to update on the fly.

If the icon set doesn't specify any DPI values, Opus will assume the icons were made for 100% scaling (96 DPI) and will scale them up if the system DPI is higher.

Yes, you need to sign-out for Windows & most DPI-aware apps to update a lot of their DPI settings/metrics. That's what this message is about when you change the primary monitor's DPI:

Clipboard Image (1)

Even apps designed for on-the-fly DPI switching do not really cope with DPI changes that well until a sign-out or reboot, as the OS itself has issues.

(Signing out will update most things. You actually need to reboot to update a few parts of the OS and their knock-on effects on other programs. In fact, there are few (fairly subtle) things which inexplicably require two reboots to adjust to a DPI change. (e.g. The heights of status bars will be slightly wrong until the second reboot.) Windows 10 works well once you are in a high DPI mode and have rebooted at least once, but still has a lot of issues when you change from one mode to another, or mix monitors with different DPIs at the same time. Also, watch out for logging in via Remote Desktop from a machine in another DPI as the first login after power-up, which makes everything messed up until a reboot if you then use the machine locally.)

I have some buttons with icons taken from individual PNG files, rather than Opus icon sets, which aren't scaling up when PNG files within icon sets are. Is this because they're also not supplying DPI values? That said, one that I'm looking at seems to say it's 72 DPI and hasn't been rescaled at all; I've manually changed the DPI to 192 and restarted the PC and it's still showing at its natural, unscaled size.

If you mean the DPI field in the PNG header, I don't think anything in the world uses that. :slight_smile: It's not a reliable field as almost nothing that makes PNGs sets it properly, so nothing could safely depend on it for general PNGs. It's only useful where the full image workflow is tightly controlled.

You can make an icon set xml that points to standalone PNG files if you want to add DPI information to them. It's optional whether or not it is zipped up into a .dis file or left as separate xml+pngs

I dropped the offending loose PNGs into a .dis with DPI awareness, so all's good now. Even went to the trouble of converting another of my .dis files while I was at it.

So a .dis doesn't have to contain the images, as long as the XML points at them? And you can also just use a loose XML file instead of a .dis. Didn't realise that.

I haven't got my usual setup on the Surface: it's only got a C: drive and I'm not yet willing to rebuild it to match my four-drive config (OS, games, user data, storage) so given that my Opus config relies on those drive letters a little too much, it's forcing me to convert to less specific paths. Given that .dis files are self-contained, that's something I won't have to worry about if I change my setup in the future, even if a .dis takes a little more maintenance than just an XML pointing at files somewhere on the system.

As a maintenance example, I've got a few PNGs I use for icons which have transparency and transparent voids: clicking on the voids doesn't register as clicking on the icon. I did this so often that I ended up bodging a fix by filling the voids with a 99% transparent alpha fill. I can't remember exactly how I did it, but instead of doing it the sensible way (i.e. fixing the full-size original and then recreating all the smaller versions) I just fixed the one size I was using. Now I have to figure out how to fix them again and update all my .dis files again. Bah.

If you're using Photoshop, just stick the main layer on top of a layer that is filled with black and set to 1% or similar.

If you look in /dopuslocaldata there should be an icon cache folder there, and Opus may have made a version of the set which is all combined into a single PNG, which may save you some time. Note that the cached PNG will have any required DPI scaling pre-applied.

I see it even creates an appropriate xml file to go with it. A nice sneaky way of converting multiple individuals into a single image. I approve.

Thanks for the Photoshop tip. I should be able to do something similar in my software.