Godot: Editor_node using .tscn

[toger5]

I was wondering if it is possible to create the godot editor with tscn's.
I even heared @reduz complaining that the editor_node is hacky/messy so using tscn would clean it up quiet a lot.
I dont really know if it is feasie though...
How much performance does it coast to parse all the tscn files.
Does it really make things easier. How much would be needed to get it working.
Things like EDSCALE would need to be added in code all over the place...

A clear advantage:
It would make the editor node structure much easier to understand.

this is just to get some opinions on that topic. And to bring up the idea for discussion. Im not claiming its a good idea...

[HummusSamurai]

AFAIK, .tscn files are converted to binary .scn when exported, so there would be no performance cost for release builds, only possibly the parsing cost for loading/saving the project code.

[bojidar-bg]

Somewhat related to #4725

[groud]

Few things make be think this is impossible:

• tscn files and binary ones, they thus are not suitable for code version control,
• To modify the editor you would need to use the editor. This is quite dangerous... as if you screw up something it might may be hard to revert.

[akien-mga]

Read #4725. It's only a small part of EditorNode which is actually the editor scene with its Controls. Most of the code is editor features implemented in C++ that you obviously can't get out of the box in a TSCN scene file. And reimplementing them all in GDScript would be inefficient and overkill (if possible at all).

[toger5]

Thank you! for linking #4725, that was a really interesting read!

I think I have to clarify what my proposal is:
Instead of converting the whole editor to a "made with godot" (gdScript...) program, I'm proposing to basically 'only' replace the initialisers of editor classes with tscn...

An example, the import dock:

the import dock currently has a control node that gets placed into the chosen dock + all the functionality when a user presses reimport + display the import options for the selected asset.

I don't think it is a good idea to replace any of the 'logic c++' but I really don't like the part of the code that is generating the control. (the Initialiser)

It is hard to read and to imagine what is parented to what, how big things are, how the overall structure is designed...
If that could be replaced by a tscn (good for version control) the import dock initialiser would be much cleaner and easier to read (I'm imagining something like this):

To modify the editor you would need to use the editor. This is quite dangerous... as if you screw up something it might may be hard to revert.

@groud
I think this wouldn't really be an issue since working with raw .tscn files is almost as hard as working with c++ created scenes.

// Pseudocode!!!
ImportDock::ImportDock() {
        import_dock_control = load("editor/import_dock.tscn").instanciate()

    imported = import_dock_control.get_node("imported_label");
    import_as = import_dock_control.get_node("imported_option_button");
    preset = import_dock_control.get_node("preset_button");
    preset->get_popup()->connect("index_pressed", this, "_preset_selected");
    import_opts = import_dock_control.get_node("property_edioor");
    params = memnew(ImportDockParameters);
}

The current Import_dock initialiser (click to reveal)

ImportDock::ImportDock() {

    imported = memnew(LineEdit);
    imported->set_editable(false);
    add_child(imported);
    HBoxContainer *hb = memnew(HBoxContainer);
    add_margin_child(TTR("Import As:"), hb);
    import_as = memnew(OptionButton);
    hb->add_child(import_as);
    import_as->set_h_size_flags(SIZE_EXPAND_FILL);
    preset = memnew(MenuButton);
    preset->set_text(TTR("Preset.."));
    preset->get_popup()->connect("index_pressed", this, "_preset_selected");
    hb->add_child(preset);

    import_opts = memnew(PropertyEditor);
    add_child(import_opts);
    import_opts->set_v_size_flags(SIZE_EXPAND_FILL);
    import_opts->hide_top_label();

    hb = memnew(HBoxContainer);
    add_child(hb);
    import = memnew(Button);
    import->set_text(TTR("Reimport"));
    import->connect("pressed", this, "_reimport");
    hb->add_spacer();
    hb->add_child(import);
    hb->add_spacer();

    params = memnew(ImportDockParameters);
}

[groud]

I don't know... For me this splits information with very little benefits, and as the tscn format is still moving (as it depends on the engine), this does not seem like a good idea.

But I totally get the advantages you can get from this system too, I am just not sure it will be maintainable easily.

[akien-mga]

C++ will fail compiling if the API changes. You can also use sed/grep or advanced refactoring tools to change things much more easily than by editing TSCN manually (TSCN is meant to be readable, not writable).

If the API changes, the TSCN will just either be broken ("ugh" message), or will discard the changed API and when you save again you'll lose part of the editor. So no, that's definitely not a good idea IMO.

[toger5]

@reduz mentioned a refactor for the editor_node once.
maybe if this makes it already easier to understand.

Closing. Since I also don't have really good points why it would make sense. just though the idea is cool ...