Skins have become very small after installing Droptop Four

[therealkn1ghtsp1der]

After I installed Droptop Four just to try it out, my Rainmeter Skins have become very small and I can't get them to go back to normal, even though I don't have Droptop Four installed anymore.

Some of the things i've tried to fix it are:
- Refreshing all of my skins
- Changing my display scaling
- Re-installing Rainmeter

all of this with 0 luck, if anyone has a solution to this problem it would be greatly appreciated

[Jeff]

Skins didn't become smaller, they are now at the correct/normal size. The effects are documented here.
Previously, all skins were enlarged incorrectly by how much you set the DPI percentage in your Windows settings, if Droptop didn't force the correct behavior, you would have noticed stuff that is meant to take the resolution of your primary monitor would go onto your second monitor (even if you don't have one, the size is still larger than your actual monitor) without making sense, you would have also noticed other options like any options that centers skins would always center skins incorrectly.
If you wanna make your previous skin bigger, you should see if they offer built-in setting skins to modify stuff like the size (for visualizer modifying the width and height should do it), some skins offer the scale just as a variable inside the skin file named Scale, just see what options the skins offer.

[Crest]

The effects are documented here.

I'm loath in the extreme to ever suggest that folks write to their Windows Registry with Rainmeter. To each his own of course.

Foreshadowing :p

If a user subsequently removes a skin manually or even Rainmeter itself there'd be no way for the skin to revert the application DPI override registry change. It's not mentioned in their FAQ and from some code searches it's unclear if even uninstalling via the project's suggested removal function reverts the change.

For the OP's clarification, the issue is that Rainmeter isn't natively DPI aware. When non-100% scaling is used Windows will naively enlarge all skins by the DPI value, causing blurry looking skins. Only if a skin has been written to include its own custom scaling (most haven't though it has become more common) can the DPI be manually overridden for Rainmeter.exe by the user (see linked thread), or in Droptop's case automatically via a registry change, so that it prevents Windows scaling skins and allows the skins themselves to apply custom scaling if they have it.

However any skins that aren't written to handle their own scaling or haven't detected the Windows DPI value will remain small with that application DPI override setting applied, which presumably is what you're seeing.

[Yincognito]

If a user subsequently removes a skin manually or even Rainmeter itself there'd be no way for the skin to revert the application DPI override registry change.

There actually is, albeit it too won't run if, say, Rainmeter or that skin crashes or experiences something that breaks the "normal flow" of operations in it. It's a rarely used option by others, though I use it for my custom tooltip skins to unload them at the same time as the main skins, see OnCloseAction here:
https://docs.rainmeter.net/manual/skins/rainmeter-section/

[Crest]

There actually is, albeit it too won't run if, say, Rainmeter or that skin crashes or experiences something that breaks the "normal flow" of operations in it. It's a rarely used option by others, though I use it for my custom tooltip skins to unload them at the same time as the main skins, see OnCloseAction here:
https://docs.rainmeter.net/manual/skins/rainmeter-section/

I suppose that could be used as a workaround at a pinch, though it has no insight as to the state of the skin installation, so would trigger if any one or more skins of suite using it were unloaded. Haven't played with setting the DPI override via the registry while Rainmeter is open but I would have expected it would require a Rainmeter restart, which would be problematic if the registry key were unloaded after Rainmeter/skin close each time.

If Rainmeter had a dedicated skin uninstall feature then something like a 'OnUninstallAction' could trigger clean-up actions (though seems the project does has a dedicated uninstall menu item but can't find code suggesting it reverts the DPI registry value). Given most skins don't manipulate the system like that it's kind of a niche scenario though.

From my observations skins that include a bunch of (non-Lua) scripts and executables often seem to be using Rainmeter to bootstrap some project that would otherwise be written in a regular compiled language and have regular installers/uninstallers. Side note but that suite auto adds an exclusion for the entire skin directory for Windows Defender anti-virus, which is pushing it in terms of impressions of trustworthiness.

My take would at least give the user knowledge and consent for whatever arbitrary things it will modify of the system and include a way to revert all of them. I responded to another user here trying to troubleshoot something that one of the Jax suite things modified and didn't clean-up after the user removed it (idk if that suite has some dedicated uninstaller). Curiously I noticed there's code in Droptop Four suite which adds a desktop shortcut to JaxCore suite so maybe there's some shared authorship.

[Yincognito]

I suppose that could be used as a workaround at a pinch, though it has no insight as to the state of the skin installation, so would trigger if any one or more skins of suite using it were unloaded.

Well, I never said the solution was ideal, but if done right and careful at every detail (too lazy to describe it here), it would work. Only breaking the normal flow of operations has the potential to make it futile. Better than nothing.