ReVanced
feat: Show the complete list of applied patches during the patching process
Feature description
This can be same as the official RV manager have. In this, instead of using a simple name that this patch been applied, having a detailed patch log/list within the manager will be good. In compose manager, list will go top to bottom, rather than bottom to top (like in RVM), within a specified area. And, after all the patches applied, the area will be automatically collapsed and shows All patches applied or 23 patches applied.
Motivation
It'll help user to see the patch list and the patch description (like in manager) and can live check the applied patches, instead of generating a log file for that or go back to patch options to see them.
Like in Hide ads, we've so many sub-options like Microsoft ads, yandex ads, etc. User will see which ads patch is applied and which not, same like RV manager.
Acknowledgements
- [x] I have checked all open and closed feature requests and this is not a duplicate.
- [x] I have chosen an appropriate title.
- [x] The feature request is only related to ReVanced Manager.
Initially, there was one element in the patching section for each patch, but that was changed a while ago. I can't remember why though and I am not in charge of design.
I was against this change back then, it was done because applying patches is "1 step" and there's no need for the user to see each patch individually
I think it'd be. Because it'll help user to see which and how many patches got failed in the manager itself, rather than generating and save a log file and see that.
Also, I think it'll somehow help in implementing an ongoing process. For eg : Currently, if one patch gets failed, then the whole patching process gets stopped in compose. While, in main rv & rvx manager, if any patch gets failed, the process doesn't get interrupted (till any major issue) and it get patched,
I think implementing this can help in resolving this issue.
Or, if you prefer, you can separately implement the ongoing process feature, so that, it doesn't get interrupted.
Because, if there are more than 1-2 broken patches, the user have to change the selections everytime, to see how many patches are broken, which is time consuming.
If you prefer, I can open s different issue for it.
The log history should not be hidden. If it is logged, it should be visible from there on. Patches for example use the logger to print some message to the user.
I was against this change back then, it was done because applying patches is "1 step" and there's no need for the user to see each patch individually
In that case, the change should be reverted.