Pivot to Non-CCleaner-as-default

[MoscaDotTo]

From a maintenance and distribution perspective, I think it would be easier, more,complete, and deliver a more robust end user experience if we pivot to maintaining the non-ccleaner flavor of winapp2 as the default one

winapp2ool is and has been at a point for a while where it can be used to generate various different versions of winapp2.ini with ease. I would like to pivot to maintaining winapp2.ini with this in mind. The end result for users probably wont look much different ideally. This may require extending winapp2ool functionality to be more concise (as with Diff to handle merges/renames recently), which is fine as winapp2ool can grow with and help this project grow.

The current approach of removed entries.ini makes sense but is applied backwards, if we have a master set of winapp2.ini entries that includes stuff that may be covered in ccleaner, then we can apply a set of at most 2 winapp2ool operations using merge to generate a ccleaner version of winapp2.ini. This can then remain the default distribution flavor

Moving away from CCleaner-only keys

I've completed some of this work already by removing DetectOS keys and most Warning keys, but we could do more. While fundametally all of winapp2.ini is in ccleaner syntax, there are certain keys that basically anything that isn't ccleaner will ignore. I think we can define the "necessary set" of keys as being {Detect, DetectFile}, and {FileKey, RegKey, ExcludeKey}. Any other key types should be considered for removal

When I was going through winapp2.ini during the recent refactor I noticed that many warnings deliver somewhat useless information, probably serving only as a mechanism to summon the warning box in CCleaner to make them think twice before ticking. One thing I tried to do as I was renaming and merging entries around is make the names of entries something more easily understood. Many warnings can be removed by this process.

Example.

[Application Backups *]
Warning=This will delete the backups for application

This is a common example in the file that I removed because this info is conveyed just as well by the name of the entry. The warning box here serves only to give the end user pause, I guess. I don't think it's strictly necessary.

Another example of a bad warning is this

[Adobe Media Cache *]
LangSecRef=3023
DetectFile=%AppData%\Adobe\Common\Media Cache
Warning=Do not use this until all your Premiere projects have been completed.
FileKey1=%AppData%\Adobe\Common\* Cache*|*.*|RECURSE
FileKey2=%AppData%\Adobe\Common\Peak Files|*.*|RECURSE

"Do not use this until all your Premiere projects have been completed." Why? What happens? There's not enough information to be useful here, so I think either the warning should be removed or the key modified in such a way that is doesnt destroy premiere projects if that's what it does. I left this warning in because I think the presence of a warning means there's something about the entry that needs to be reconsidered. This is the case with some other warnings too

Moving to sections: or removing LangSecRefs
LangSecRef keys mean nothing to applications that aren't ccleaner, generally, and switching to sections would give us more flexibility in how we classify applications in the UI of CCleaner. Particularly as I have diverged our naming scheme from being coupled to that of CCleaner's, and so winapp2.ini entries who are related to ccleaner entries

Alternatively, we can simply diffuse the LangSecRef keys into something that is inserted into only the CCleaner flavor

Likewise, if we switch to some other classification method for entries, we can investigate storing entries in separate ini files by these categories. winapp2ool can easily be modified to support maintaining these files and building winapp2.ini from them

Creating the ccleaner flavor
As I mentioned before, the non-ccleaner system is backwards. We have all these entries labeled as being "extras" and in the context of ccleaner truly they are, but they're not extra, they're just part of those applications, many of which we have entries for. In this context, we may give non-ccleaner users something like [Application *] and [Application Extras *] and even the two of them together don't cover the breadth of what an application generates because the original [Application *] entry was written to supplement an existing [Application] entry in CCleaner. Very confusing!

It makes much more sense for us to have one entry that has everything which we then either overwrite or remove entirely to accommodate what ccleaner supports. We can do this with a series of patches:

The default winapp2.ini containing all entries is first generated (or maintained, as is the current paradigm, but I have thoughts on this)
We apply a merge operation to remove any entries who are whole-sale not needed. If we go full coverage and create entries for internet caches, cookies, etc, then those entries with ccleaner analogs would be removed as part of this process
We apply a second merge process to add any entries we need to, and also to replace any entries we need to modify with "ccleaner-variants"

This would result in us having a base [Application *] entry which covers the same scope as [Application] + [Application *] + [Application Extras *] which we then apply a patch to modify to the current version of [Application *] that we deliver in the ccleaner flavor. This presents no extra change to the ccleaner-flavor user but provides a much better experience to non-ccleaner users.

[APMichael]

These are also good approaches.

My personal opinion is meanwhile the following: I would almost go over to ignoring the entries in CCleaner and only offer a Winapp2.ini with complete entries. Very many entries in CCleaner are outdated and do not support newer application versions. Furthermore I am very disappointed by the quality of the entries added to CCleaner in the last months (e.g. because of syntax errors, forgotten detects, incomplete function, illogical entry names, ...). It should not really matter if the Winapp2.ini entries partially clean the same files/folders. The only exception are the entries for cookies, because CCleaner offers the possibility to keep certain cookies - which cannot be implemented with the Winapp2.ini.

(CCleaner is not doing itself any favors by constantly adding new unnecessary features and neglecting the main task, cleaning up the system, more and more. And when something new is added to the cleanup function, it is sloppily implemented. Very sad...)

[MoscaDotTo]

Yeah I have no interest in achieving parity with CCleaner on its many outdated entries, but there will no doubt be overlap for things like browser caches, etc. We can resolve the case where we oversupport for ccleaner by applying a patch to prune things ccleaner already supports though so it's not much of a problem. This approach would also allow us to more easily create other flavors of winapp2.ini which is something im interested in as well, since we'll have a more unified non-ccleaner variant as the basis

[MoscaDotTo]

The original basis of excluding content that was already included in ccleaner was because items would be counted twice during the scanning phase, it didn't have any effect on the actual cleaning except that if you had an entry disabled in ccleaner which was a subset of an enabled winapp2 entry, it would still get cleaned... so I feel like the approach of full content first and remove the ccleaner bits rather than disjointly adding back the removed bits just feels more natural while still delivering the same end user experience to ccleaner