Bring in improvements from other gdnative libraries
rosshadden opened this issue · 4 comments
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?
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
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 ☝️ 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.
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?
Yes, that one is an engine module and doesn't use GDNative or NativeScript.