Rework: Addons

[ItsTheSky]

This PR aims to enhance add-on integration into SkEditor, with fewer hard-coded things, and make add-on developers' lives easier. The list of ideas for rework below is subject to changes if I have new ideas. Current addon developers are welcome to talk about this :) (c.f. @GliczDev)

Current To-Do

• Enhance Addon's Icons
• Let them register & handle third-party connections
• Add support for bottom-bar modification (right side)
• Add support for sidebar modification
• Supports custom addons settings in their own (separated) page
• Supports custom DLLs/NuGet Packages directly via SkEditor (without giving the files)
• Let addons require other addons
• Let addons manage Files/Editors
• Add welcome tab (similar to VSCode)
• Enhance file saving system
• Let them register a new documentation provider
• C# Docs for implementations

Other Related Rework

Deprecation of ApiVault

• API Class separated into multiple sub-class
• Make SkEditor itself uses the new SkEditorAPI class

Requires textmate/skdoc PR #55

• Let them register file type, syntax theme, syntax lang
• Let them handle tooltips (they can show custom tooltips in the code when they want)

[GliczDev]

Since addons are being reworked, I think these things should be considered:

• ApiVault deprecation. API shouldn't be accessible thru static instance. It's the same problem as Bukkit class in Bukkit API - vanilla sever jar doesn't store static server instance, it's designed to run multiple server instances (which e.g. Minecraft Realms does), however Bukkit adds static server instance, which breaks this design. SkEditorAPI instance should be injected into addons.
• Addons should have a file like Bukkit's plugin.yml. Searching for class implementing IAddon isn't very performant and allows addons to create multiple IAddon classes (idk if SkEditor's addon loader ignores them).
• Addons should be able to depend on other addons.
• Many events are missing. I don't remember rn which I actually needed for analyzer, however I complained a lot to @NotroDev about that so he should remember ;)

And that's all I can think of right now, good luck working on that with my pookie bear Notro 🥰

[ItsTheSky]

ApiVault deprecation. API shouldn't be accessible through static instances. It's the same problem as the Bukkit class in Bukkit API - vanilla sever jar doesn't store static server instances, it's designed to run multiple server instances (which e.g. Minecraft Realms does), however, Bukkit adds static server instances, which breaks this design. SkEditorAPI instance should be injected into addons.

I agree. Addons will be given to a SkEditorAPI instance within the class. For SkEditor itself which uses ApiVult a bit everywhere, I suggest splitting the features into several other classes (logs, windows, ...)

Addons should have a file like Bukkit's plugin.yml. Searching for a class implementing IAddon isn't very performant and allows addons to create multiple IAddon classes (idk if SkEditor's addon loader ignores them).

Even with a "data" file for addons, we'll still have to instantiate their IAddon class (for registries and all), so around performance, we should be around the same anyway. To avoid add-ons creating multiple classes I think we can just check the namespace of the classes, and if they are similar make an error (that would also avoid addons version conflicts)

Addons should be able to depend on other addons.

Yup, it's planned an addon will be able to load before or after another addon. How will it handle this internally? I have no single ideas yet xD

Many events are missing. I don't remember rn which I actually needed for analyzer, however I complained a lot to @NotroDev about that so he should remember ;)

Gotcha, maybe @NotroDev would point them out as I'm working on this PR :D

[GliczDev]

Even with a "data" file for addons, we'll still have to instantiate their IAddon class (for registries and all), so around performance, we should be around the same anyway. To avoid add-ons creating multiple classes I think we can just check the namespace of the classes, and if they are similar make an error (that would also avoid addons version conflicts)

I mean, "data" file for addons would be also useful for specifying dependency on other addons. It would be also nice to be able to declare libraries that SkEditor would automatically download for addons (something like Bukkit's libraries section in plugin.yml), however I think it should be done like Paper plugins libraries (https://docs.papermc.io/paper/dev/getting-started/paper-plugins#loaders)