Move GDExtension out of Scripting/Programming languages

[adamscott]

It seems odd that GDExtension is sorted within Scripting/Programming languages of the manual.

This PR makes it available directly in the Manual TOC.

[adamscott]

Especially with that note from within the What is GDExtension? page

[AThousandShips]

You still need to rename the references in the documentation, the redirects are for external references I think

[YuriSizov]

I think putting a section called GDExtension at the top level can be counter-productive. If a person knows about such a thing, they will use the search, or a search engine even, to find the relevant documentation. But if they don't know what it means, then the title is pretty obscure.

I would aim to have a section for low level engine extensions instead, something that covers GDExt and, perhaps, custom modules.

[dsnopek]

I have mixed feeling about GDExtension under Scripting.

On the one hand, it is a little deceptive, given that classes added in GDExtensions don't act like scripts. But on the other hand, it's nice having GDScript, C# and GDExtension on the same list, given that those are the 3 main ways that you could program your game. And, once we have "gameplay classes" (see godotengine/godot#82554 - hopefully something we can do for 4.3), GDExtensions could be used in a way that is closer to scripting. And, of course, there are already GDExtensions that add new languages through the script API (Python, Lua, etc), and using those, GDExtension is enabling scripting.

I would aim to have a section for low level engine extensions instead, something that covers GDExt and, perhaps, custom modules.

This also makes sense, especially when thinking about godot-cpp, because godot-cpp aims to be as source compatible with modules as is possible. However, there's more than godot-cpp, for example, the Rust bindings.

Maybe if we had a section about modules, we could have a part in there that addresses doing the same stuff but using godot-cpp? But that's only one way to use/think about GDExtensions.

Anyway, I don't have any solutions to contribute. I'm just pointing out more things that make it hard to find the right home for GDExtension. :-)

[AThousandShips]

I'd say it should be under plugins if not under scripting

[skyace65]

I have no strong opinions on where it should go. But you need to remove the reference to the page in the scripting section index file, it's why the CI build is failing.

[YuriSizov]

This also makes sense, especially when thinking about godot-cpp, because godot-cpp aims to be as source compatible with modules as is possible. However, there's more than godot-cpp, for example, the Rust bindings.

Maybe if we had a section about modules, we could have a part in there that addresses doing the same stuff but using godot-cpp? But that's only one way to use/think about GDExtensions.

I think we need to differentiate GDExtensions themselves and tools that extensions power. I think language bindings are more of a latter, and to end users this would be on the same level as scripting. But for extension developers it's not like scripting, it's closer to modules.

So I wouldn't consider that angle, I think. It's too confusing to mix together the extension framework itself and scripting capabilities enabled by it through third parties. Of course your point about gameplay classes stands, but to that end we can still have GDExtensions under scripting to cover that part specifically, when it's ready.

[adamscott]

Maybe if we had a section about modules, we could have a part in there that addresses doing the same stuff but using godot-cpp? But that's only one way to use/think about GDExtensions.

The difficulty here is that modules are akin to the "contributing" part of the docs. But, by nature, GDExtension is not about "contributing", but building your own private modules.

[adamscott]

You still need to rename the references in the documentation, the redirects are for external references I think

I just added the single reference to "scripting/gdextension" in the whole project. It was in the Android plugin page.

[dsnopek]

I think the tricky bit is that GDExtensions can be about a lot of different things. :-)

The current C++ example really is a scripting-ish example. It's not doing something you'd do in a Godot module, and it's using virtual functions that I wouldn't recommend if you were doing something module-ish (ie _process() rather than _notification()). So, it does sort of fit in Scripting.

To me the question is:

1. Do we want to have a GDExtension section with sub-sections that explain all the different things that GDExtension can be about, including: using GDExtensions, doing gameplay coding for your game, extending the engine like a module, creating a language binding (and there's really two ways to do that: adding a scripting language, or making an alternative way to make GDExtensions), etc..

2. Or, do we want to scatter sections about GDExtension through out the docs near the different use cases. So, talk about how to use GDExtension to do gameplay coding for your game in the Scripting section. Talk about using it to make module-like things near where we talk about creating modules. Talk about using GDExtensions near where we talk about addons. And so on.

[adamscott]

I would personally go with option 1. I think that GDExtension stuff should be set together rather than exploded throughout the manual. But, we could have articles throughout the manual that refers to GDExtension, like a stub, that say: for more info about scripting using GDExtension, see that article in GDExtension.

[akien-mga]

I agree with most points above, which makes this change hard to validate, because I don't see any good/natural solution.

If we have GDExtension as top level, then as a user I would find it quite weird that GDScript and C# are nested two levels deep in Scripting > Programming languages when GDExtension is top level. So maybe we should consider moving GDScript and C# to top-level too.

And if so, maybe we want to split them out of Manual which is very crowded, into a new Programming category? (Alternatively, "Scripting & Bindings" but that's quite lengthy.)

If we create such a Programming category, we could also move Plugins to it I suppose.

This would then bring the question of what to do with the Scripting section once its "Programming languages" subsection was emptied. The other section seems to be "Core features" https://docs.godotengine.org/en/stable/tutorials/scripting/index.html#core-features which I admit I wouldn't expect to look up under "Scripting" (mostly because I know Scripting is where we put the programming languages stuff). Maybe also something to put top level, but this one still under Manual. "Core features" is a bit vague as a name, a lot of this stuff seems to be what was in the old Getting Started guide.

You're kicking a very complex can of worms here :)

[dsnopek]

I would personally go with option 1. I think that GDExtension stuff should be set together rather than exploded throughout the manual. But, we could have articles throughout the manual that refers to GDExtension, like a stub, that say: for more info about scripting using GDExtension, see that article in GDExtension.

That could work! Although, I suspect some of these "stubs" could still turn out to have quite a bit of content.

For example, like I said earlier, it's nice that when you look at "Scripting" you see GDScript, C#/.NET and GDExtension, as those are the 3 avenues that a developer should consider when deciding how to program their game:

But that GDExtension Scripting page should probably explain that you can either (1) create your own native GDExtension that handles gameplay stuff, or (2) install a GDExtension that lets you script in Python, Lua, etc. And the page explaining what those things mean for the developer (so they can decide what link to click next) could still end up being kinda long.

[YuriSizov]

Maybe if we had a section about modules, we could have a part in there that addresses doing the same stuff but using godot-cpp? But that's only one way to use/think about GDExtensions.

The difficulty here is that modules are akin to the "contributing" part of the docs. But, by nature, GDExtension is not about "contributing", but building your own private modules.

I think we should definitely divorce docs about custom modules from contributing. There can be some repetition of the information and cross references, but in general creating modules is not a part of contributing. We don't need new modules often, and when the need arises finding the docs elsewhere in the documentation for it is fine.

[mhilbrunner]

Closing due to lack of consensus. Seems clear that there is consensus that something can be improved here, but we should discuss what and how before making more changes. Thanks!