[Suggestion] Skin uninstall button in Manage Rainmeter

[killall-q]

With .rmskin reducing the learning curve of adding skins to zero, it's ironic that the task of removing skins is still so primitive and technical. I expect that a significant portion of Rainmeter users now are the sort who are only interested in graphical jazz and have a distaste for editing, syntax, and folder structure. I know it's not much of a stretch to expect them to figure out Documents\Rainmeter\Skins and it's not a big deal, I just think the current solution is inelegant.

That said, is trashing the skin folder enough? If not, how might local fonts and plugins be handled? (If only more authors used local font...) Might Rainmeter scan every config? Perhaps a separate "clean up" button that does that? Given Rainmeter's simple script-based nature, that wouldn't take long. Or might Rainmeter build a registry from raininstaller.cfg files it encounters? Too many holes in that one, I think.

[smurfier]

I believe the easiest way to accomplish this would be to have Rainstaller, or the author, include a file in the root of the installed skins directory listing all folders and/or files installed. It would probably be best to leave this task up to the skin author. Then it would be easy to write a tool to look for these files, list them, and then delete the files/folders listed in those uninstall files.

My only problem with this is the potential security risk. What's to stop someone from uninstalling something important?

[jsmorley]

There is just no way to make any kind of automated "uninstall" for skins safe or reliable. Addons and Plugins can be shared by multiple skins without any knowledge of the sharing, that is the intent of having a common folder for them. There is no way I ever want a skin uninstalling a font from Windows, as it has no way to know that it is both the thing that originally installed it, and that only it uses it. Skins are often just one folder that can easily just be deleted to remove the skin (and I would not oppose this simple functionality in Manage), but are just as often part of a "suite" of skins that have dependencies in order to use shared images, include files, or who knows what. There is no way to have Rainmeter parse a skin to figure out all the possible dependencies in order to do any kind of reliable and safe deletion of an entire suite. Don't forget that skins can !ActivateConfig other skins, which may have their own dependencies, in a recursive tree that has infinite possibilities.

This whole thing is something we have looked at, particularly in the context of the new Manage dialogs. While we think it might be appropriate to have a "delete this folder" on the right click of a folder in the tree in Manage, which would allow for easy deletion of the probably 60% of skins that are just stand alone in a single folder, it is not our intention to try to take this any further in the current Rainmeter architecture.

While it is true that an author might well create some process to delete his own stuff, we are not going to get in the business of telling authors how to code skins, and in any case there are still huge dangers with deleting plugins, addons and fonts, even if you THINK you put it there.

Some of the team however, are beginning to move our thinking away from the Addons and Fonts folders in \Rainmeter approach. The reason for this is two-fold. First, it eliminates the problems folks occasionally run into with "version conflicts", particularly with addons. Second, it does move us in the direction of having more if not most skins easy to get rid of by simply removing the folder they reside in. While we again don't intend to force any particular way of doing things on authors in the current architecture, we are beginning to think that at least the shared "Addons" folder may have been the wrong way to go. The thinking was to only have one copy each of common utilities like NirCMD or RainRGB on a user's system, and to save hard drive space by doing so. The disadvantage of version control problems, combined with the fact that almost all of these kinds of utilities are extremely tiny, has changed our thinking on this.

The point of this is that if authors tend to move toward keeping everything used in their skins (aside from plugins of course) IN with their skins (any addons, LocalFonts included in the folder, etc.) rather than installing things to Rainmeter's common folders, then the approach of simply deleting the folder to "uninstall" a skin becomes more reliable, if not certain.

In a related matter, I am of the opinion that a Rainmeter skin should NEVER install a font to Windows. LocalFont should always be used. Installed fonts use Windows resources even when not used, and I personally don't think skin authors should take this responsibility, nor take it upon themselves to install something in a user's Windows system when the user may well be running Rainmeter in "portable" mode or even from a USB at a friends house. Just always use LocalFonts. There is no downside.

In my latest JSMeterV suite, I moved to an approach of:

JSMeter
--Addons
--LocalFonts
--Images
--Sounds
--Clock
--System
--Weather
etc...

I have made it so removing JSMeter\ at the highest level gets rid of the entire suite without putting other skins at risk. This might be an approach others should consider.

[AlC]

Yah ... maybe a button "Delete Skin/Suite", that delete the Skin/Suite-Folder and the Section [Skin/Suite] in the Rainmeter.ini
And in the case of the "Delete Suite" button it could delete the Suitefolder in the AppData folder.

This would be the 3 things that I would delete with a "Delete" button.

[jsmorley]

I might be ok with cleaning up Rainmeter.ini based on the folder deleted, since there is a one-to-one relationship with a folder that describes a "config" and a section in Rainmeter.ini. Probably have to do this to implement any "delete folder" at all, as if you delete a folder containing a skin that is currently loaded in Rainmeter, it will just come off the rails.

The problem is that some suites have dozens, and a few lots more, "skins folders". The routine is probably going to have to recurs through all the folders before it deletes them, and build some list of every "config" and parse Rainmeter.ini looking for matches. Then "unload" each if it is currently running, and then and only then delete the folder. This is going to be a fair amount of code. The other option is just to deny "delete" to any folder containing a currently loaded config, but that is probably just as much code.

I would never recommend messing with "themes" though. A theme can have any name, and there is no certain connection. The fact that you deleted a folder called AnalogClock might well mean you want to delete a theme called AnalogClock, or it might not. You may have a setup that uses dozens of other skins and you just happened to name the theme AnalogClock since that was ONE of the skins you used in it. A theme has nothing at all to do with a suite in any programmatic way. It is purely the choice of the skin author if he wants to name things in a way that makes it appear so. I wouldn't touch it with a ten foot pole.

Basically I'm suggesting a simple delete folder capability in the Manage tree, and even that is a fair amount of work. Any thinking about making it into a logical "delete skin" instead of a physical "delete folder" just heads us back down the rabbit hole that ends in something that either has us trying to forces rules on authors ("if you want this to work, you have to code and name your skin/suite/theme this way") which is both not what we want to do and doomed to certain failure, or just doesn't work consistently or safely.

Anyway, we will keep this suggestion in mind as we move forward. It's on the list...

[killall-q]

Neither additions to the .rmskin format nor recursive searching should be necessary. You've got all the fonts in the Rainmeter\Fonts folder, all the addons, and all the plugins in Array A. Parse every config and make a list of all the fonts, addons, and plugins mentioned and make that Array B. Subtract from Array A stuff from Rainmeter initial installation + Array B, and you've got your loose ends. LocalFont only works in the [Rainmeter] section and requires stating the full name of the font file.

Anyways, something of that complexity is probably best off as a separate utility, and even then the benefit would be trivial, as the list of third-party addons in circulation is minuscule.

I was just hoping that a streamlined method of uninstalling would eventually lead to lesser-known authors getting more downloads, as oftentimes I've not downloaded a skin just because I didn't want to face the hassle of removing it if I didn't want it. Especially when it comes to the Skin of the Month poll, few people are going to actually download and try all 6 skins to see how well they work instead of just judging by the screenshot.

[jsmorley]

I understand. I agree with the intent for sure. I'm telling you though, that these kinds of things sound easy and reasonable until you meet up with the devil, who lives on details street.

Don't forget that any skin can have .inc files (so much for LocalFonts only being in the [Rainemter] section of the skin) and those .inc files might have measures or meters that use ActivateConfig to open other skins in entirely different folders, and those skins can have their own dependencies anywhere on the user's system. Addons can be executed in any of about a dozen ways, and can be shared with multiple skins that may be called from hundreds or even thousands of folders not in the path you are deleting. You may have multiple users on a computer sharing a single \Skins folder, but with a different Rainemter.ini for each account. Then throw in the fact that ANY of this can also happen from bangs sent by .lua script files that the skins use. I haven't really done the thorough mental "unintended consequences" analysis I generally do when trying to move from "idea" to "design", but the complexity of such a tool is already staggering.

[smurfier]

I'm still leaning towards the author created uninstall file. If that file does not exist then you either delete the main folder or do it manually.