Godot: Development of the editor on the basis of scripts

[ret80]

Currently editor of the engine is implemented in C ++. It has its advantages and disadvantages. On the benefits I will not say I want to hear them from you. Let's talk about the shortcomings.
1 The increase in compile time. Not the biggest disadvantage. Yet if you do based on the script editor you can reduce this time.
2 The complexity of development. C ++ harder than Godot script.
3 Weak customization. What would make changes in the editor will have to rebuild the engine. If he was on the script editor can be directly changed by itself in the process of project development.
Of course all this is not an indicator that would drop everything and remake editor c ++ on Godot script. Still, it may be worthwhile to move in this direction. Especially since there are examples. For example, "Kakos creator" and "urno" exactly what do. perhaps someone else.
It turned out as it is messy. I'm sorry if that :) Who thinks about this?

[ghost]

It's an interesting thought but what about the performance then?

And with the plugin system we do have (do we have it anymore?) we can simply add features to the editor by writing GDScript scripts and without rebuilding the engine and writing the plugins in C++.

[neikeq]

Considering that many things are not exposed to GDScript and the performance penalty, I don't see this viable.

[ret80]

What kind of performance loss is it?
If pa script editor does not allow to realize it is very sad and is probably something to do with it. There are 2 solutions. Either change the scripting language or slightly expand an existing one.
In addition, the script editor on the basis of immediately show all the shortcomings of the script. This will correct them at the stage of development of the engine.
In general, I see only positive things.

[neikeq]

GDScript is way slower than C++. I don't see the point of re-write all the existing editor code in a slower language.
IMO the _cons_ beat the _pros_.

[ret80]

And it slower?
The editor does not generate constant work. Basically he is waiting for commands from the user. And his task is to move something somewhere or change some or property. In fact, all the components will remain at "C ++". Tolka logic moves to a script. I believe that your fears are not justified nothing. There are also additions to the editor, and they are made to the script. And nothing more. Problems do not arise.

[ret80]

Please Give an example that you will slowly be executed in the editor. What the editor require C ++

[jkb0o]

This is almost here: http://godotengine.org/qa/58/how-to-create-editor-tools-in-gdscript.
Im trying to do the VertexSnap plugin for spatial using only gdscript with some success. And I really enjoy the way editor is written. I'm not sure about Cocos creator and urno, but I've worked with Unity a lot. It looks like extendable editor at first, but it is really slow and buggy (as whole Unity is) when you work with a lot of assets. And you can't change this, or this changes costs too much. Writing plugins for Godot means you can write it fast using GDScript (already, with some limitations), and if you have some bottlenecks just port this code to C++.

[RebelliousX]

The only advantage I see from this is accelerated developement of Godot. If I understand this issue right, that is by making the GUI using gdscript as external files from the main executable, there would be no need to recompile the whole engine to modify the scripts.

But as @neikeq said, performance penalty might outweigh the advantages.

[ret80]

Everyone is talking about the fall of performance but who are not brought not a single serious argument in favor of the fact that it will happen. Everything is just expect. Which is not a constructive conversation turns.
With the same success I can only assume that the editor of the translation to improve all the script and performance too. Arguments will not lead. What for?! I guess :)

[ghost]

just benchmark the speed of gdscript and c++ and you will see what we mean. The loading of the editor is slow anyways and the importing of models and other assets and it will get even worse if we would have used gdscript.

[akien-mga]

I'm not sure you understand the complexity of the editor. If it's just about skinning, place GUI elements at some place and so on, it can indeed be done via GDScript and it would be cool. But the editor has _functionalities_, most of which can't be coded in GDScript if there is no C++ backend. And such functionalities often imply manipulating big arrays of values, doing a lot of math operations (think e.g. about the light baking plugin, or drawing big convex polygons, etc.).

So basically what you ask for would be that everything stays coded in C++, i.e. still the same amount of work, but on top of that the editor layout should be done in GDScript. It itself it might sound appealing, but actually it doesn't make editing the editor easier; it implies that editor hackers would have to know GDScript AND C++, as you can't make editor functionalities with only GDScript (unless you use the EditorPlugin API, which is the way to go).

[ret80]

The conversation with a deaf mute! Thank you discovered the secret about the fact that the c ++ faster. I guess as it is not (sarcasm).
How much slower will import models? I imported the model and it is happening fast. If the transition to slow script 3-4 times this is not essential. You can wait. Since the model is not imported every 5 seconds and is rare.

[bojidar-bg]

Well, I personally don't want to wait _a lot_ for every reimport, or (oh my) importing of large fonts. Also, consider the many (many) things the editor is, in fact, already capable of doing. Some of them will get more then 3-4 times slowdown probably.

On another note -- do you consider the time needed for such a change? I guess 2-3 weeks of development would be used for just the conversion, and all PRs that impact the editor would have to be merged beforehand or _closed_.

[ret80]

I see that the support of my proposal does not. Perhaps then I will cover this topic.

[jkb0o]

Well, after some diving into editor, I am ready to look at this topic from a different point of view. There is a lot of parts of editor written using Godot api itself. I've seen a code like below here and there:

tb = memnew( ToolButton );
tb->connect("pressed",this,"_tool_selected",make_binds(TOOL_INSTANCE, false));
tb->set_tooltip(TTR("Instance a scene file as a Node. Creates an inherited scene if no root node exists."));
filter_hbc->add_child(tb);
button_instance=tb;

vbc->add_child(filter_hbc);
filter = memnew( LineEdit );
filter->set_h_size_flags(SIZE_EXPAND_FILL);
filter_hbc->add_child(filter);
filter_icon = memnew( TextureFrame );
filter_hbc->add_child(filter_icon);
filter->connect("text_changed",this,"_filter_changed");

scene_tree = memnew( SceneTreeEditor(false,true,true ));
vbc->add_child(scene_tree);
scene_tree->set_v_size_flags(SIZE_EXPAND|SIZE_FILL);
scene_tree->connect("rmb_pressed",this,"_tree_rmb");

Hey! This looks like scene! Wait a minute... But Godot already has scenes as resources. What if we move this code into "scene_tree_editor.tscn"? Some c++ logical code may looks cleaner if it written in GDScript as well (yield is amazing btw). Just keep performance-expensive code at c++ side. Moving in this direction, we can achieve all main three points provided by @ret80. Even more - Godot Editor will be written using much more Godot itself.

Well, I know how it is an expensive process. And how many other thing should be done. So I choose to keep this direction in mind and learn more editor code to make a better proposal at some point.

[ret80]

jjay - Hooray, at least someone over. I can open up again. But still I think that it is not will not give any result.

[jkb0o]

I am for opening and keep it open for a while. This is discussion anyway =)

[ret80]

at the request of the working people :)

[bojidar-bg]

@ret80 Note that I'm not particularly against the idea. I criticized it so that the weakest points of the proposal are exposed early :smile:

Also, you shouldn't be so fast to close it, since that's what the discussion tag is for - to make sure new proposals are as good as possible.

[reduz]

not a chance, for something this large, a statically typed is generally much more maintainable as it makes refactoring easier as well as understanding what every thing does.

dynamically typed languages are great for small pieces of code and embedding, but they are a huge pain in the ass to do refactoring.

[reduz]

that said, we have an upcoming plugin API for extending Godot in GDScript, so a large part of new functionality can be done with this.