feat: More plugin metadata options

[cswimr]

I think it'd be beneficial to add some more metadata for plugins rather than just name and description, so plugin authors can provide useful information like issue reporting links, repository links, and just... being able to credit themselves without having their name in the plugin name or description. Metadata provided in a top-level [gauntlet] definition that isn't defined in children [[entrypoint]] definitions should be inherited from the parent.

Proposals:

Note: None of these should be required/mandatory, just optional metadata.

• Authors field
  • Should be an array of either objects or strings
    • example: authors = [{"name":"cswimr", "url": "https://github.com/cswimr"}]
    • example: authors = ["cswimr"]
  • If strings are used instead of objects, urls will not be rendered
  • Renders in the settings UI as Author: [name](url) (assuming markdown formatting), or Authors: [name](url), [name](url)
  • This specifically should be usable in entrypoints as well.
• Repository field
  • Simple string/url that points to the git repository
  • Renders in the settings UI as Repository: url
• Issues field
  • Same as repository, just points to the plugin's issue tracking, whether that's on the repository or elsewhere.
  • Renders in the settings UI as Issues: url, or alternatively, as a "report issue" button if present
• Description field
  • Yes, this already exists, but I'd like to be able to use markdown formatting inside of descriptions. This might warrant its own issue, I'm not sure.
  • Descriptions supporting markdown, if implemented, should also be usable in entrypoints.

[cswimr]

Didn't consider this when writing this issue yesterday, but a version number would also be nice!

[BennoCrafter]

plugin version should be a publish timestamp and displayed as formatted date

[cswimr]

plugin version should be a publish timestamp and displayed as formatted date

I disagree, although a Publish Date field populated automatically by Gauntlet wouldn't be bad. I'd like to be able to specify the versions of my plugins independently, so I can follow versioning conventions (like semver for example).

[Exidex]

@cswimr the problem with that is npm run publish only supports one version at a time. the whole "using git repo as plugin hosting" approach doesn't bode well with multiple concurrent versions

[Exidex]

@cswimr Also I am not sure that letting user choose the version of the plugin is a good UX

[BennoCrafter]

How about adding a title field like raycast does? That way, name is a unique id (e.g. dev-plugin1), while title serves as the display name.

[BennoCrafter]

What about a general supported OS field? For example, users should only be able to download plugins compatible with their OS. e.g., not being able to download a Homebrew plugin on Windows.

[Exidex]

@BennoCrafter

supported_system plugin manifest property is already implemented. there will be error in settings view when trying to download plugin that is not supported on current system

about the title, not sure i understand. there is already a plugin name, and plugin id is a git url which is more or less unique

[Exidex]

I have added authors field to plugin manifest gauntlet.authors.*.name and gauntlet.authors.*.uris.

I am not quite sure about Repository and Issues fields for similar reasons. Because plugin id is an url where it is hosted, and issues can usually be found in the same place. Technically just adding turning plugin id into a click able link would have the same effect in most cases.

Description should be turned into markdown, latest iced has markdown widget so it shouldn't be difficult to add, if somebody wants to make a pr