Add PluginConfigDialog.

[willnationsdev]

Here are a host of small changes that were all part of #19778. Someone please let me know which parts of this people wanna discard, and of those remaining, which ones I should merge into single commits (or if I should just roll all of these commits up into one, etc.).

[swarnimarun]

Nice work atleast you didn't give up I know I would have.
I would love a number of these changes.

[reduz]

As I mentioned before, most of those are solutions in search of problems, or things that need a lot more discussion. We can leave this open and eventually discuss this stuff when time comes

[willnationsdev]

@reduz, well, true, in their current state, the majority of these just give answers to a now nonexistent set of problems (most deal with problems I encountered while building my own changes).

The ones that are more usability-focused that solve real issues are...

1. The GDScript can_instance method taking into account the presence of a can_instance method on the GDScriptInstance - applicable to the existing custom type system...I think? (Edit: pretty sure this can be used anywhere since it'll check the can_instance method when deciding whether to instance the script. So it isn't just for custom types).
2. Rebuilding documentation tool. Creates a simplified GUI for something that usually must be done on the command line.
3. The PluginCreateDialog and it's related changes create a simplified GUI for editing plugin configs which previously required direct text editing. It also makes it possible to generate files for creating a plugin.

Everything else most certainly addresses no-longer-existing problems.

[willnationsdev]

If people like the PluginCreateDialog idea, I can move it into a different PR to be merged while the others are in limbo / discussed. Or if you just wanna wait on them all, that's fine too. I'll be around, so let me know. 👍

(I trimmed the PR so only the significant stuff remains for discussion)

[Zylann]

I like the PluginCreateDialog. In fact I was thinking about PR-ing one, since it is useful, saves time, improves discoverability and shipping it as a plugin itself is awkward.

[willnationsdev]

Should I just extract the PluginCreateDialog into its own PR, or leave it in here, assuming people will discuss the usefulness of the docs rebuild / abstract GDScript commits?

[akien-mga]

I don't see the point of this feature.

Rebuilding documentation is only relevant when you made code changes and compiled them, and since that usually happens on the command line, it's much easier to run --doctool directly.

It's even more wrong if you're using the official Godot binary, as it's not in bin/ next to the doc/ directory as your feature hardcodes it, so it will just dump a full documentation tree in an unexpected location in ../doc.

[willnationsdev]

Well, the idea (at the time) was to be able to have the doctool generate content for XML files in your project folder / plugin folders too. Combined with the ability to generate XML files from a Script, this would allow you to create in-engine documentation for the scripts in your project. And in a case like that, being able to easily rebuild stuff from the editor would be useful.

However, it's a fair point that all of that is predicated on features that aren't even implemented yet (script-based XML generation, generating docs from local files rather than just the godot repo).

I can go ahead and remove it from this PR.

[akien-mga]

Please don't use relative paths, the root folder is already in the include path so you can do #include "scene/gui/check_box.h".

[akien-mga]

Just FYI, you could use WARN_PRINTS("Can't call non-static function: 'can_instance' in script."); directly.

[willnationsdev]

Since I never mentioned it, this PR has been redesigned so that it's just the PluginConfigDialog changes. Should be good to go.

[akien-mga]

Thanks!