Bring in improvements from other gdnative libraries

pragmagic / godot-nim

Nim bindings for Godot Engine

https://pragmagic.github.io/godot-nim/

Other

497 stars 28 forks source link

Bring in improvements from other gdnative libraries #66

Open rosshadden opened 4 years ago

rosshadden commented 4 years ago

Some other gdnative libraries have raised the bar quite a bit in terms of usability / user experience since this project was first created. I will list some examples:

ECMAScript, C#, and Python add entries to the attach script dialog:
None of the above require creating .gdns files (or embedding in scenes)
Of these, only C# seems to require a manifest file with each included script, but it generates the file automatically so I only noticed because of the git diff. Based on what I saw when experimenting, I'm guessing the "create script" action calls a method in the C# library which it uses as a trigger to generate or add to the file.
godot-python is self-contained and available in the asset store (I know this one is a stretch and don't think it could be done with godot-nim, at least not easily)
C# and ECMAScript don't even require a .gdnlib file

Are we able to add any of these improvements to this project?

sheepandshepherd commented 4 years ago

None of those are NativeScript bindings, they're engine modules (except Python) that add fully-featured subclasses of ScriptLanguage/Script/ScriptInstance for their language. NativeScript is a different, much more minimalistic, thing. It doesn't allow adding languages to the Attach Script dialog or the internal editor, and strictly requires .gdnlib/.gdns files, because it's designed to never even know about your source files.

There are partial solutions for NativeScript bindings, like editor plugins or build scripts that auto-generate .gdns/.gdnlib files, or import source files as .gdns resources (for C++, Rust, and D).

I'm guessing the binding authors are unlikely to migrate to an engine module or PluginScript - it'd require a lot of rewriting and extra work, and would introduce some disadvantages over NativeScript. Improving NativeScript itself might be a more realistic option. Related issue: godotengine/godot-proposals#119

rosshadden commented 4 years ago

Interesting, thank you for the detailed explanation.

There are partial solutions for NativeScript bindings, like editor plugins or build scripts that auto-generate .gdns/.gdnlib files, or import source files as .gdns resources (for C++, Rust, and D).

I think that idea :point_up: combined with a godot proposal I opened in 2018 and migrated yesterday to godot-proposals, as well as the proposal you linked would make the Nim+Godot workflow much better.

ShalokShalom commented 3 years ago

None of those are NativeScript bindings, they're engine modules (except Python) that add fully-featured subclasses of ScriptLanguage/Script/ScriptInstance for their language.

Wait, also EcmaScript?

sheepandshepherd commented 3 years ago

Yes, that one is an engine module and doesn't use GDNative or NativeScript.