Display and install dependencies

[sylae]

This isn't quite a fix for #6, but I think it's a good middle point until such time as the API supports dependency autoinstalls.

(That being said, I'm pretty sure you could auto-install dependencies without changing the API. It'd be a little jank, but you could store the ident of the plugin you're trying to install, then if it fails, see which .Dependencies aren't present. I was considering writing this, but I suspect we'd prefer a more elegant approach. If we wanted to do this, the dep manager pulls all the data to facilitate it)

One item of note is due to API limitations I'm making a few requests to /api/plugins (one for each page). If there was a way to get all items at once, that might make more sense for this. IDK what the server-side limitations are tho.

[codecat]

Looks awesome! Before I dive into the code for this, I have a couple thoughts that immediately come to mind that I think should be discussed in one way or another:

• Why do plugins have a "required dependency" icon if they are not a dependency, but a dependent? (The top-most tree nodes, for example at the very top "Autosave Ghosts")
• Showing the version number of plugins shipped with Openplanet is not necessary, as they are always going to be 1.0 (I never change them, as they don't update with the plugin manager.)
  • Additionally, we might not even need to show the author either, since it's kind of implied that the author is "Openplanet" (or in many cases just me)
  • Maybe plugins shipped with Openplanet could have a separate icon in the list as well, to indicate where they come from.
• When should the dependencies tab be displayed? I think always displaying it could be confusing, as people always expect the tabs to be some sort of repository of plugins. Perhaps it should only be displayed when clicking some option in the menu?
  • Sidenote: I've never liked how the "Installed" tab looked much, either. Perhaps we could think about merging the two tabs into one, and then using your design for the dependencies as the main style for this.
  • Additionally, maybe a complete re-design of the plugin manager is in order, but this would be better discussed in a new Github issue.

For the API, I will have to implement a new API to get numeric ID's from identifiers, much like how the update check currently works (you can pass multiple numeric ID's to get results on multiple plugins).

[sylae]

• Why do plugins have a "required dependency" icon if they are not a dependency, but a dependent? (The top-most tree nodes, for example at the very top "Autosave Ghosts")

That's an oversight on my part, it's an easy fix tho so no biggie!

• Showing the version number of plugins shipped with Openplanet is not necessary, as they are always going to be 1.0 (I never change them, as they don't update with the plugin manager.)
  • Additionally, we might not even need to show the author either, since it's kind of implied that the author is "Openplanet" (or in many cases just me)
  • Maybe plugins shipped with Openplanet could have a separate icon in the list as well, to indicate where they come from.

Yeah, I'm thinking maybe instead of NAME by AUTHOR (vVERSION) it could be like OPENPLANETHEART NAME (builtin)? idk

• When should the dependencies tab be displayed? I think always displaying it could be confusing, as people always expect the tabs to be some sort of repository of plugins. Perhaps it should only be displayed when clicking some option in the menu?

  • Sidenote: I've never liked how the "Installed" tab looked much, either. Perhaps we could think about merging the two tabs into one, and then using your design for the dependencies as the main style for this.
  • Additionally, maybe a complete re-design of the plugin manager is in order, but this would be better discussed in a new Github issue.

I was thinking maybe it could be a popup that appears when a plugin has unmet mandatory deps, but also having a way to access it manually for optional dependencies would be nice. I could do some mockups of UI ideas but it's certainly not my strong suit so 😛

For the API, I will have to implement a new API to get numeric ID's from identifiers, much like how the update check currently works (you can pass multiple numeric ID's to get results on multiple plugins).

that'd be pretty poggers, maybe something like /api/plugins?names=Ident1,Ident2,etc?

[codecat]

Yeah, I'm thinking maybe instead of NAME by AUTHOR (vVERSION) it could be like OPENPLANETHEART NAME (builtin)? idk

I think it shouldn't show the v prefix in any case, since we don't really use that prefix anywhere for plugin versions.

I was thinking maybe it could be a popup that appears when a plugin has unmet mandatory deps, but also having a way to access it manually for optional dependencies would be nice.

I think that makes sense. I'm not sure where the menu for this would be located though. Either in the main menu (which might be too much clutter) or we create a new menu in the plugin manager window (which might only be 1 singular option, and that might be kind of a waste of space).

that'd be pretty poggers, maybe something like /api/plugins?names=Ident1,Ident2,etc?

Yeah, something like that. I'll let you know about the actual API when it's implemented.

[sylae]

Pushed some more fixes to take advantage of the website api changes in the pipeline. This vastly reduces the overhead caused by the Dependency Manager, as well as adds dependent plugin info to the PluginTab ui:

The Install button has also been adjusted to automatically install any required dependencies automatically, with a tooltip indicating as such.