feat: Documentation 2.0

[prateek-who]

This is a work in progress! We don't push this until after the GUI update pretty much.

The entire docs/ folder will be only have images folder and the new single documentation.md file.

How does this look so far? What other changes should we make to this file?

[LisoUseInAIKyrios]

Looks good so far.

I think this could work well, where the most basic usage is covered in the readme and the more expanded usage (especially the CLI) is in the document MD file.

A few links to the documentation need adjusting (link doesn't exist).

I think the documentation developer page can be deleted entirely. If anyone is developing for CLI they can refer to the documentation repo which contains the same info and more.

The strips libs instructions could be moved from the readme to the dedicated documentation file.

[prateek-who]

Yea, the links don't exist right now, but will fix them. I'll slowly make the new documents.md file with your updates

[l205306]

Is it possible to add a keystore file from path ?

[prateek-who]

Is it possible to add a keystore file from path ?

Yup. Use the --keystore flag to add your keystore

[prateek-who]

One other thing I realized, the apk/apkm that we provide to patch is positional in patch subcommand. Do we instead make it a flag too?

In InstallCommand it is a flag:

@Option(
        names = ["-a", "--apk"],
        description = ["APK file to be installed."],
        required = true,
    )

[LisoUseInAIKyrios]

Changing that might mean breaking existing usage compatibility, unless both positional and arguments work.

Should install be changed to positional instead? Then it's the same as patch and list-patches.

[prateek-who]

We could make it both both positional and arguments.
In install, the ADB devices serial no. is the positional argument. Yet another positional argument.

[prateek-who]

Check the CLI section once now and suggest if there are any improvements/ suggestions/ corrections. Would be lovely if @wchill took a look at it too.

[prateek-who]

https://x.com/lydiahallie/status/2027129030571634721

Interesting stuff from Anthropic

[LisoUseInAIKyrios]

Now we just need another 2.5k stars in Manager repo.

[prateek-who]

Now we just need another 2.5k stars in Manager repo.

lmaoooo. They also have " Don't quite fit the criteria? If you maintain something the ecosystem quietly depends on, apply anyway and tell us about it."

That Max 20x plan looks quit tempting ngl

[wchill]

Luckily, I already get unlimited usage via copilot thanks to work.

[wchill]

I would add a note somewhere about --force being needed in order to patch versions other than recommended, since a lot of users like to patch experimental versions.

[prateek-who]

Could we not add like those small chips that say [Youtube | 20.40.45 (recommend version)] under the morphe logo for the cli and manager maybe? That way the user knows which version is the latest. I know the user can find it out through the app and cli but just a small QoL suggestion.

[LisoUseInAIKyrios]

Where does this text appear?

[Youtube | 20.40.45 (recommend version)]

[prateek-who]

Right now, it doesn't appear anywhere, but I meant something like this:

We mention the app name and the latest supported version

[LisoUseInAIKyrios]

Oh in the repo readme.

That would be more useful for the patches repo itself instead of CLI repo.

Patches release.yml could be changed to generate/modify the patches readme to show all patches and compatible versions, similar to what RVX does in its readme (see it's release actions how it does it). This change could be part of the patches-template project so third party repos have an easy way to show their patches.

[prateek-who]

Oh in the repo readme.

That would be more useful for the patches repo itself instead of CLI repo.

Patches release.yml could be changed to generate/modify the patches readme to show all patches and compatible versions, similar to what RVX does in its readme (see it's release actions how it does it). This change could be part of the patches-template project so third party repos have an easy way to show their patches.

will look into it. I have never worked with .yml files

[LisoUseInAIKyrios]

See https://github.com/inotia00/revanced-patches/blob/3c6a371e32f2f15f8de6c9ed66126df4fbab7efb/.github/workflows/release.yml#L35 and see the Java code for that gradle task.

I would add a second gradle task that updates readme and updates patch bundle JSON files (or if somehow each task can be split apart into two different actions where one only updates patches json and the other only updates readme). So patch repos can pick if they want to only update patch JSON files (required for release), or if they also want to update their readme too.

The dev work can be done without modifying the yml file. It's a gradle task that can be run locally to update readme. If you want to try, modify morphe-patches repo and after it's merged we can apply the same changes to the template repo.