Jump to content
CCleaner Community Forums

Winapp2.ini

Beta Testers
  • Content count

    6,373
  • Joined

  • Last visited

Everything posted by Winapp2.ini

  1. Winapp2.ini additions

    Welcome! *** Please Read *** The entries contained in winapp2.ini are not endorsed or supported in any way by the developers of CCleaner. This file is very large in its complete form and can cause significant delays when launching CCleaner. You can tailor the file to your system configuration and optimize CCleaner's launch time using winapp2ool's Trim module. While we do our best to ensure that submitted entries are not harmful, it is possible that some entries can impact the normal functionality of your system or applications. Winapp2.ini is provided "as is" and as such, neither I nor Piriform hold any liability for damage done to your machine in the event of an issue. If you have any questions, comments, concerns, or issues, please either file an issue on GitHub or make a post in this thread. *** Thank you *** GitHub Direct Download Winapp2ool releases Latest winapp2ool beta build (stability not guaranteed, beta builds only notify about updates to newer release versions) ReadMe for creating entries Enjoy! Looking for old content? Our litany of old scripts/programs have been replaced with functions in winapp2ool. Check it out! You can also file bug reports on GitHub (this link may include open entry requests - feel free to fulfill them either here or on GitHub :))
  2. The Firefox/Mozilla Thread

    Enabling BITS on nightly for me results in the update downloading only after pages have loaded
  3. Winapp2.ini additions

    I think the Clover entry is correct as it is, IIRC.
  4. The Firefox/Mozilla Thread

    The new firefox branding seems to be launching
  5. Winapp2.ini additions

    Would those filekeys be okay in [Windows Logs *]?
  6. Winapp2.ini additions

    I think the same is true of the ExcludeKey's paired RegKeys
  7. Winapp2.ini additions

    https://github.com/MoscaDotTo/Winapp2/issues/383
  8. The Firefox/Mozilla Thread

    https://blog.nightly.mozilla.org/2019/05/22/these-weeks-in-firefox-issue-59/
  9. The Firefox/Mozilla Thread

    https://hacks.mozilla.org/2019/05/firefox-67-dark-mode-css-webrender/
  10. The Firefox/Mozilla Thread

    It's functional but lacking support for things you'd expect from mainline firefox (ie. webextensions support - planned but not implemented in GeckoView). I haven't experienced any issues but i use Focus as my default browser and only spin up Fennec or Fenix sparingly It's definitely worth checking out if you're interested, it does not conflict with any existing Firefox installations on your phone
  11. The Firefox/Mozilla Thread

    Fenix is now available on the Play Store through the beta/nightly process. https://events.mozilla.org/becomeabetatestingbughunter This is the upcoming rewrite of Firefox for Android (fennec) to be based on GeckoView (a la Firefox Focus and Reference Browser). It's been available via task cluster for a while but being on the playstore means automated installs etc
  12. Winapp2.ini additions

    I added a link directly to the Creating Entries section of the ReadMe to the top level post. For sanity/version control reasons, it's much easier to link to GitHub resources from this thread than to maintain separate copies
  13. Winapp2.ini additions

    Would all subkeys of \Profiles\Outlook\***** necessarily be a profile folder? If so this wouldn't be too difficult to create support for, I don't think.
  14. Firefox Extensions REBOOTED

    My nightly seems unaffected by this bug. I have the message saying the addons can't be verified but they all still work. Weird. Addon signing is probably not a requirement on the nightly build if I had to guess edit: seems my xpinstall.signatures.required is set to False
  15. Winapp2.ini additions

    Oh I know! In the immediate future, I'm looking towards implementing unit tests, but winapp2ool has some in-progress ideas for metascripting entries, a windows store application one would fit in well
  16. Winapp2.ini additions

    I hear minefields can be dangerous
  17. Winapp2.ini additions

    A build of winapp2ool with the non-ccleaner ini being a commandline arg (-ncc) is now available. The menus in diff or trim might be broken under some circumstances, but I think I got most of the adjustments correct. https://github.com/MoscaDotTo/Winapp2/tree/Branch1/winapp2ool/bin/Debug
  18. Winapp2.ini additions

    Agreed, I think it should be moved to winapp3.ini specifically The backups folder becomes polluted with backup files that notepad++ has "forgotten" over time, mine has over 40 0kb backups of files that I never created. Normally I'd say we should just remove it because most users wouldn't want to delete these, but given this issue I think there's a case for the usefulness of the entry
  19. Winapp2.ini additions

    This change was made across all modules under the assumption that most people would usually want to download the latest. The default download setting now matches whether or not you have an internet connection. I actually just had the realization that this has likely had the affect of also inverting any commandline args for downloading (outside the download module) as I typed this response, so I've reverted the change on the development branch. You can find an executable with the behavior you want here: https://github.com/MoscaDotTo/Winapp2/blob/Branch1/winapp2ool/bin/Debug/winapp2ool.exe I'd also like some feedback on whether or not the non-ccleaner setting should be shown or if it should be behind a commandline arg (eg winapp2ool -ncc) which would set winapp2ool to non-ccleaner mode. The user facing change here would be that all the separate menu options for the non-ccleaner version would no longer be shown and the winapp2.ini options would select the appropriate file for your current mode. If for some reason someone wanted to still use the combined mode, I could leave support in for that through some other arg, but I would imagine there are not many people frequently interacting with both copies at the same time. In the near future I'm hoping to extend the commandline arg handling to better enable people to use winapp2ool however they want in a scripted fashion, which should hopefully eliminate the need for potentially confusing menu setups like this.
  20. Winapp2.ini additions

    winapp2ool update: v1.02 https://github.com/MoscaDotTo/Winapp2/releases/tag/v1.02
  21. ublock users

    Mozilla could end up down this route too: https://blog.mozilla.org/addons/2018/10/26/firefox-chrome-and-the-future-of-trustworthy-extensions/ Manifest v3 “In 2019 we will introduce the next extensions manifest version…We intend to make the transition to manifest v3 as smooth as possible and we’re thinking carefully about the rollout plan.” In 2015, Mozilla announced we were deprecating our extremely popular extension system in favor of WebExtensions, an API compatible with Chrome, as well as Edge and Opera. There were several reasons for this, but a large part of the motivation was standards — a fundamental belief that adopting the API of the market leader, in effect creating a de facto standard, was in the best interests of all users. It was a controversial decision, but it was right for the web and it represents who Mozilla is and our core mission. Three years later, while there still isn’t an official standard for browser extensions, the web is a place where developers can quickly and easily create cross-browser extensions that run nearly unchanged on every major platform. So I would like to publicly invite Google to collaborate with Mozilla and other browser vendors on manifest v3. It is an incredible opportunity to show that Chrome embodies Google’s philosophy to “focus on the user,” would reaffirm the Chrome team’s commitment to open standards and an interoperable web, and be a powerful statement that working together on the future of browser extensions is in the best interests of a healthy internet.
  22. ublock users

    https://bugs.chromium.org/p/chromium/issues/detail?id=896897&desc=2#c23 Comment 23 by rh...@raymondhill.net, Yesterday (32 hours ago) In the design document, it is said that the webRequest API will no longer allow to be used in blocking mode: > In Manifest V3, we will strive to limit the blocking version > of webRequest, potentially removing blocking options from most > events (making them observational only). Content blockers should > instead use declarativeNetRequest (see below). It is unlikely > this will account for 100% of use cases (e.g., onAuthRequired), > so we will likely need to retain webRequest functionality in > some form. From the description of the declarativeNetRequest API[1], I understand that its purpose is to merely enforce Adblock Plus ("ABP")-compatible filtering capabilities[2]. It shares the same basic filtering syntax: double-pipe to anchor to hostname, single pipe to anchor to start or end of URL, caret as a special placeholder, and so on. The described matching algorithm is exactly that of a ABP-like filtering engine. If this (quite limited) declarativeNetRequest API ends up being the only way content blockers can accomplish their duty, this essentially means that two content blockers I have maintained for years, uBlock Origin ("uBO") and uMatrix, can no longer exist. Beside causing uBO and uMatrix to no longer be able to exist, it's really concerning that the proposed declarativeNetRequest API will make it impossible to come up with new and novel filtering engine designs, as the declarativeNetRequest API is no more than the implementation of one specific filtering engine, and a rather limited one (the 30,000 limit is not sufficient to enforce the famous EasyList alone). Key portions of uBlock Origin[3] and all of uMatrix[4] use a different matching algorithm than that of the declarativeNetRequest API. Block/allow rules are enforced according to their *specificity*, whereas block/allow rules can override each others with no limit. This cannot be translated into a declarativeNetRequest API (assuming a 30,000 entries limit would not be a crippling limitation in itself). There are other features (which I understand are appreciated by many users) which can't be implemented with the declarativeNetRequest API, for examples, the blocking of media element which are larger than a set size, the disabling of JavaScript execution through the injection of CSP directives, the removal of outgoing Cookie headers, etc. -- and all of these can be set to override a less specific setting, i.e. one could choose to globally block large media elements, but allow them on a few specific sites, and so on still be able to override these rules with ever more specific rules. Extensions act on behalf of users, they add capabilities to a *user agent*, and deprecating the blocking ability of the webRequest API will essentially decrease the level of user agency in Chromium, to the benefit of web sites which obviously would be happy to have the last word in what resources their pages can fetch/execute/render. With such a limited declarativeNetRequest API and the deprecation of blocking ability of the webRequest API, I am skeptical "user agent" will still be a proper category to classify Chromium. --- [1] https://developer.chrome.com/extensions/declarativeNetRequest [2] https://adblockplus.org/filter-cheatsheet [3] https://github.com/gorhill/uBlock [4] https://github.com/gorhill/uMatrix
  23. Winapp2.ini additions

    This would affect the "Microsoft.XboxOneSmartGlass_8wekyb3d8bbwe" package, is it part of the Xbox app too?
  24. Winapp2.ini additions

    Happy holidays!
  25. Winapp2.ini additions

    the tools folder and its now-deprecated contents are also removed from the repo, with the exception of the winappool executable and its version file for watershedding.
×