[DISCUSSION] A friendly interface

[nonunknown]

Here we can discuss the best approach for the interface, I'll made a blueprint and show here soon!

For mine I've used a popup, you've seems to be using the Output bottom tabs. I was thinking using it as main screen control like file editor plugin:

the goods of using this way, is that when the user has too many classes, there's no issue to seeing them! Also classes listing should be something like Multiple selectable items so the user can delete multiples at the same time, (checkboxes can be a good approach when user wants to build ignoring some classes)

[SIsilicon]

Now that you mention it, since the native scripts are technically scripts, it does sound like a good idea to give them their own screen; maybe even have their source code editable from Godot too.

[SIsilicon]

I'm making a mockup screen now to see how it would look.

[willnationsdev]

@SIsilicon I'm not sure I'd go that far. I actually (thus far looking at the addons) much prefer your approach of using a bottom panel, especially since it better matches the way Mono support works (it's a context-sensitive viewer panel).

If you really want official script editing support for a language then it should be done with a PluginScript, not NativeScript, and that's not what these native integration tools are designed to help with. At least, that's my thought on it.

Even if you manage the content from Godot, I would still expect people to primarily edit the files from a separate dedicated text editor with existing tools for syntax highlighting, autocompletion, and other things related to the language in question.

[SIsilicon]

Oh yeah, I definitely agree with editing the source from another application. I mean like, to be able to at most, preview the source code. Definitely don't want it to be the main editor of said source code.

[willnationsdev]

@SIsilicon If all someone wants to do is preview the source code, that should already be doable with the existing ScriptEditor or, as a last resort, the existing FileEditor plugin maintained by fenixhub.

[nonunknown]

yeah agree with @willnationsdev , for that a option called "Import source files after build" is doable when users want to share their native source code.

Now about the bottom panel, it will be a problem when lot of classes need to be managed!

[SIsilicon]

Ok, gotcha.

[nonunknown]

unless whe have a button to popup a window that can show a lot of classes at same time!

[willnationsdev]

@nonunknown

Now about the bottom panel, it will be a problem when lot of classes need to be managed!

I fail to see how it would be a problem. You would conceivably have just as much space as the FileSystemDock, and the library/class stuff should probably be modeled in a similar manner. Something like...

| ----------------------
| - Library1 
|     - Folder1
|         - Class1
|         - Class2
|     - Folder2
|         - Class3
|         - Class4
|         - Folder3
|             - Class5
| - Class6
| - Library2
|     ...

Just use a Tree node inside of a ScrollContainer and you can do pretty much everything you need from there.

Have a different icon on the left depending on whether something is a library or a folder, and then if it's a class, use a default "class" icon or the script class icon if one is defined for the resource.

Then allow users to choose where any given LibraryN should exist (in res://, in user://, in Editor files, etc.). res:// is for if they want source code bundled with their project (i.e. in the same git repo). user:// is if they want to maintain it in a separate repository, but still make it associated with that Godot project, and Editor files would be for cross-project content that Godot can naturally make available without external tooling (like directory junctions and other hard links in the operating system).

[SIsilicon]

Now about the bottom panel, it will be a problem when lot of classes need to be managed!

See, that's thing. The list is a scroll container so it would never run out of room. Plus, there is a button to expand the bottom panel too, so I doubt space would be an issue as @willnationsdev states.

[nonunknown]

hmm thats ok then, about naming, is better using Library instead of Project?

[SIsilicon]

I think Project would be a more confusing name, since you can have multiple libraries in one project. Plus, the name Library reflects the GDNativeLibrary resource, which is the main resource that contains the built binaries, and is used by NativeScripts.

[willnationsdev]

Library, since Project is already kind of used by Godot Engine itself. BUT, it's also a fact that any given "library" could really consist of multiple compiled libraries that have interdependencies, so I'd almost think we need a whole different term, similar to how Visual Studio uses a "solution" to hold multiple "projects". Not sure if we should use the same terminology, but, something to that effect.

[willnationsdev]

There should be a 1-to-1 ratio between an explicit collection of source files that are intended to be compiled together into a dynamic library and any given GDNativeLibrary resource. But you might have multiple GDNativeLibraries that need to exist separately and also be compileable together as a single unit.

That's why, in my original proposal, I suggested having generic GDNativeBuild resources that define all the information necessary to execute a build, and why they also have child Build resources for nested/recursive building. That way you can do some form of dependency management with all the source code packages being independently operable with all necessary build information adjacent to the code.

[nonunknown]

Wait, for example its possible to this?

user compiles HelloWorld.cpp and generate Hello.dll
user compiles OtherClass.cpp + Hello.dll and generate NewLib.dll

if not, I was thinking on something called "merge libraries" which would imply in copying source files in another library LOL

[willnationsdev]

@nonunknown Yeah, either that, or something where the headers/source files/dependent library lists all get merged into a single trio of master lists at the top level of the hierarchy and are built into their own .dll.

user compiles HelloWorld.cpp and generate Hello.dll
user compiles OtherClass.cpp + Hello.dll and generate NewLib.dll

Yes, OR

user compiles HelloLib: [HelloWorld.cpp] > generate hellolib.dll
user compiles NewLib: [OtherClass.cpp] + HelloLib.Files > generate newlib.dll

If nesting the dlls is possible, that'd be better though.

[nonunknown]

awesome, creating with source files is better due to x-platform compiling

[nonunknown]

Then allow users to choose where any given LibraryN should exist (in res://, in user://, in Editor files, etc.). res:// is for if they want source code bundled with their project (i.e. in the same git repo). user:// is if they want to maintain it in a separate repository, but still make it associated with that Godot project, and Editor files would be for cross-project content that Godot can naturally make available without external tooling (like directory junctions and other hard links in the operating system).

Source files are mandatory to be in Editor Data Folder, local sources only for versioning (copy of EDF ones)

[SIsilicon]

Wouldn't the project's source code make more sense to be within the project? Auto importing can easily be nullified by using .gdignore.

[willnationsdev]

@SIsilicon not if you want to have independently developed libraries that are shared between projects (like, actual Godot C++ addons).

[willnationsdev]

Granted, you could always just mandate that in-project files be used, and have users handle the decision of how to get files from one project to another. But if we wanted to have the plugin facilitate that stuff for them for package management, then you'd need it to actually do the work of keeping the files in a separate location on the computer.

Now, maybe I'm wrong, and it's not a good idea to keep the files separate? Idk. The simplest way to answer the question would be to just create a poll on Twitter/Reddit and try to get feedback from the community about what they would actually want to do in practice (since those are what problems we should be solving).

If you do end up using the addon system for all the work, and make the users handle it themselves, then eventually whenever an addon-sharing package management system is developed, people's native script addons would automatically get that same support. So, whatever solution we come up with, it might be a good idea to ensure that it at least supports the in-engine stuff naturally, but then can also support more if necessary (for the short term ability to share code more easily).

[nonunknown]

yep, if the files where inside project, we couldnt benefit from reuse bindings and sources from other projects too easy!

@willnationsdev this pool makes no sense for me, since its more about cross-project stuff than usability!

[SIsilicon]

Hmm, well in that case it could just be an option.
Either make a library editor wide, or project wide.
Both options have their places.

[willnationsdev]

@SIsilicon Yeah, I think that's more or less what @nonunknown means when he mentions having the ability to copy files from a centralized location to the project. Users should have the option to choose in which place they keep the files, and we can automate moving the files for them for that purpose.

[SIsilicon]

@nonunknown , @willnationsdev , so during testing, I discovered a downside of the tkinter python module. It's not guaranteed to be part of a python installation so it doesn't always work.
Fortunately, I thought of an even better solution. Each language can have its own "configuration template". This template will be a special json file that stores data about each of the build options, including what platforms are supported from each host platform. This template can be duplicated whenever a new library is created. It can then be read by the build dialog and a sort of "inspector" can be generated from the config file; just like how GDScript uses _get_property_list() to expose properties to the inspector.

[SIsilicon]

Here's what I have so far. The build options GUI was made entirely from script.

This is the config file used.

{
    "host_supported_platforms": {
        "windows": [
            "windows",
            "android"
        ],
        "linux": [
            "linux",
            "windows",
            "android"
        ],
        "osx": [
            "osx",
            "linux",
            "windows",
            "android",
            "ios"
        ]
    },
    "target": "debug",
    "build_options": {
        "use_mingw": {
            "value": false,
            "description": "If true, Mingw will be used to compile to Windows instead of Visual Studio.\nOnly applicable on Windows host platforms."
        },
        "use_llvm": {
            "value": false,
            "description": "If true, Clang will be used to compile to Linux instead of GCC.\nOnly applicable on Linux host platforms."
        },
        "android_ndk_path": {
            "value": "",
            "description": "The path to the android NDK root. \nRequired to compile to Android.",
            "hint": "IS_FOLDER"
        },
        "xcode_path": {
            "value": "",
            "description": "The path to XCode. \nRequired to compile to iOS.",
            "hint": "IS_FOLDER"
        }
    }
}

[SIsilicon]

UI update!

You can now view the source files of the classes from the built-in editor. There's also a script button beside the libraries and classes that open their source files with an external editor.

[SIsilicon]

What do you think?

I recently watched a video about Godot in C# (never did that before), and I got a glimpse of the Mono panel. This makes it look closer to that.

[SIsilicon]

Hi, I'm back! Was thinking about this plugin and wanted to leave this idea out. We should definitely have some sort of auto-build functionality like Mono.
Whether the user is running the project, deploying to the web or android, or exporting from the editor or command line, the appropriate libraries are generated on the fly.
I'm thinking that an EditorExportPlugin could be used for this.