Godot UI Improvement Suggestions

[swarnimarun]

The is a suggestion post which I was wanting to make for some-time now.

Here are some ideas that I think that Godot should probably work on,

1. Godot can have the ability to pop out docks as windows. What I mean is I would love to be able to just snap out the Texture Region Tool and use it on a separate monitor or just make it full-screen to be able to use it more easily. Similarly, for Shader Editor.

2. Godot IDE/Script tab be able to be popped out to a separate window too, I really would like to have it on a different monitor if I have one. Especially helpful for Visual Scripting.

3. Godot docks to be more draggable and not just be using the fixed positioning system.

4. Godot should have a system like scene-view(2D/3D) and game-view(2D/3D) and just switch to game view when the play button is pressed and a separate window should not be required. This might be a challenge but the benefits make it worth it I believe,
   Some benefits are:

• You will never see the scene and game view together and so, no double rendering performance decrease. Newbies suffer from this alot.
• It will also not need another window, when we have too many windows already.
• Now using remote tab to check on the properties in Inspector will become more common. I was thinking about it ever since the remote tab was added to Godot.

5. Lastly Godot can also add ability to add plugins as windows. Similar to Unity. If you don't know Unity. Then it can be explained as having a separate window in which the plugin will be loaded and it will have a set size and can be used to create plugins that require more space than the old ones. This should be simple once the first 2 points are made possible. Probably we can create a EditorPluginWindow class.

Hope this helps with understanding the features required to make the Godot UI more Robust. And the game engine more user-friendly for newbies.

[toger5]

I like all of them!
I'm especially interested in the multi window support. There already were a bunch of discussions on this but i think no simple enough solution until now.
Any ideas how to pull this off?

Since it is the engine which rubs the editor multi window support apso benifits all the projects made with godot which i think is phenomenal!

[reduz]

1. and ..
2. are planned at some point, though this is only useful for people with multiple monitors. Godot works really well on notebooks or computers with a single monitor.
3. A bit more flexiblity may work, but so far the fixedness of godot layout is more or less considered to be a good thing.
4. Not happening, because Godot runs the game in a separate process. Due to this, a game view is not possible. but maybe it could be possible to dock the game somehow to the editor. Really difficult to do though. With a separate window there is not any performance limitaton, beceuse the editor is not redrawing all the time. Also, with the current system, you can do live editing without losing changes.
5. You can already do this, and when window undocking is supported, it will work out of the box.

[swarnimarun]

@reduz I knew that the 4th was probably is not possible(too difficult) but it was sort of worth a shot.
It is mentioned by many people and I have tried that having my 3D scene open and then playing the game affects performance. So I just wanted some kind of solution. Probably just stop rendering of scene when play is hit or just switch to script tab.?

And I think the flexibility additions should atleast be to the options of what we can do. For now if not a separate window being able to maximise the shader and texture region tab will really help.

I really don't like to type in the shader tab if the monitor is of small size like my laptop. And editing texture regions on huge sprite-sheets is a pain. I believe it would be fixed by some sort of texture splicing feature like in Unity but until then.

And if the first and second are planned is there a release for which they might be in, probably in later releases of 3.1 or directly in 3.2, cause it's a real problem to be able to get separate windows and having to code and check the scene again and again, and it's almost makes the workflow unbearable if I am creating a tool script. Which like to do often.
I could then just set the scene to update always and Voila the perfect workflow.

It can even be used on any monitor with enough screen real-estate. 2K and 4K monitors which are becoming quite common now will benefit and UHD ones to.

@toger5 I am not familiar enough with the Godot internal API to give suggestions and even if I was I am still only learning C++.

@reduz And also, another suggestion is the at least the ability to dock at all the places and for all items even the shader and texture region tabs if that will be easier. Although I don't know if that's the case so just asking.?

[mhilbrunner]

reduz:

1. and ..
2. are planned at some point, though this is only useful for people with multiple monitors. Godot works really well on notebooks or computers with a single monitor

It does, and we should strive to keep it that way. But I believe for professional development, having >1 screen(s) is more common than not. Even for a laptop, it is common to hook it up to a second display. Currently, this is really limiting in Godot, there are multiple views for which this would be very nice:

• as mentioned, the code editor. However, this can currently be worked around somewhat by using an external editor on another display
• editing multiple scenes side-by-side, i.e. editing a character or prop scene on one display, seeing how it looks placed in a scene on another. This is very important, especially for fast iteration during prototyping/lookdev
• editing animations or gridmaps/tilemaps on one display, seeing the result in-scene on another

Really happy to hear it is planned!

Edit:

Probably just stop rendering of scene when play is hit or just switch to script tab?

That sounds like a good stopgap solution to that issue.

[reduz]

editing multiple scenes side-by-side, i.e. editing a character or prop scene on one display, seeing how it looks placed in a scene on another. This is very important, especially for fast iteration during prototyping/lookdev

This would require a rewrite of a large part of the editor. Probably doable, but incredible amount of work for not so much benefit (well, i guess faster scene switching for large projects could be a benefit). You can still do this with live editing already anyway, so it's pretty low on the list of priorities.

Probably just stop rendering of scene when play is hit or just switch to script tab?
That sounds like a good stopgap solution to that issue.

Yes this should be relatively easy to do, we could force refresh to like, 1 second or something in the editor is not in focus and the game is running.

[reduz]

I really don't like to type in the shader tab if the monitor is of small size like my laptop. And editing texture regions on huge sprite-sheets is a pain. I believe it would be fixed by some sort of texture splicing feature like in Unity but until then.

I think the bottom panel needs a maximize button (and corresponding shortcut) you can toggle it to full-size and back, never really got around doing this, but should be super easy to do if anyone is in the mood

[eon-s]

If editing scenes side by side is too hard to make (or a mess, if you think of the scene tree docks) maybe a way to "apply changes to original scene" can be done for instanced scenes with editable children (like a prefab behavior), for a similar use.

[reduz]

@eon-s not sure about that, because changes are local overrides in Godot. Changes to materials will go back to the original scene because they are shared, though. Still, again, you can do live editing and see how your changes look in real-time, so not quite sure why this is needed.

[eon-s]

Changing to the isolated scene to change adjust things, then going back to the main scene to see it, can be annoying to the point that may be faster to discard instance and re-save as scene and overwrite the old one.

That scenario is something that can happen when fine tuning scenes to look right when placed on a level or when comparing many scenes that need to have some common defaults (can be props, pieces of UI, characters).

[henriiquecampos]

4. Godot should have a system like scene-view(2D/3D) and game-view(2D/3D) and just switch to game view when the play button is pressed and a separate window should not be required. This might be a challenge but the benefits make it worth it I believe,

That's something that I'd like to see as well...but currently all proposals are very "Unity-like", so how about that:

We already have Local and Remote scene tree, everything is kept until a sync button is pressed, then the Scene in the editor updates all its parameters to sync with the remote scene, there's no need to always update them, it only sync the properties once the button is pressed, than with the "Sync Scene Changes" property from the Debug menu turned on in the Editor, the user can tweak with the Local scene and the Remote will update. And if he/she wants to keep the new scene settings, the user just need to save. The sync "button" could be a hotkey in the Editor, just like we have for Play(F5), Pause(F7), Stop(F8)...

I proposed this like...2 years ago in #7169 But I don't know how to implement it. I even prototyped it ;-;

[Zylann]

• 1, 2 and 5 --> Support for multiple screens (Split scenes / gdscript) #9059
• 3 --> Dockable Container #8250
• 4 --> Game Button and Mode For Seamless Experience #5802

[groud]

1, 2 and 5 --> #9059
3 --> #8250
4 --> #5802

Yeah, I was pretty sure about existing issues for each point. I wonder if this should be closed as a duplicate. I'll let @akien-mga decide.

[chanon]

@reduz actually @mhilbrunner gives some very valid reasoning for being able to edit scenes side by side at:
#9059 (comment)

I agree live editing should be good enough workaround for now though.

[chanon]

I agree with all the suggestions here except for running the game inside the editor (No. 4) as it seems it would need a hack to implement and it doesn't really provide much benefit and Live editing also requires having the non-running scene visible.

One other thing that might be related to these suggestions is that when editing resources it is sometimes fiddly as to keeping the resource 'selected'. For example to edit a shader assigned to an object, I click on the object, then the material in the inspector, then edit shader. I make adjustments and then run the game to see results. If I accidentally select another object or maybe I need to edit something on another object, the selected shader becomes deselected and the Shader editor tab disappears. I then have to click the object and click to edit the shader again. When tweaking a shader or other resource types, this cycle repeats many many times.

It would be nice if you could keep resources open as their own tab somehow. Then you would be able have multiple shaders open at once and they would stay open until you close them. Maybe there could be an icon that you can click on to promote a resource editor tab into a full tab that stays open.

It kind of makes sense especially for resources that are their own files that you should be able to keep them open and keep many of them open at the same time.

[Zephilinox]

Since the godot editor uses the godot engine, couldn't having a game window be achieved by just instancing the root node of the game project within a viewport or something? It would need #20091

[toger5]

@Zephilinox yea thought about that too... everything would need to be a tool script though.

you can play around with it already by creating a plugin and just adding a viewport which shows the image of a 3d camera of your scene. and make all the scripts tool scripts.

[Zylann]

I recently played with the opposite way: since my use case for this would just be to see the scene from different point of views as it runs, I simply made a tool that runs ingame and allows me to spawn additional viewports to see other parts of the scene as I play. Works fine without modifying the game, if event handling is done right :)

[Two-Tone]

I had no idea that the editor itself was based on the very engine it's for (is it really? That seems almost... perverse for some reason). If that is indeed the case, the idea of instancing the root node within the editor seems like a very elegant solution.

…

On Sun, Jul 15, 2018, 9:34 AM Marc ***@***.***> wrote: I recently played with the opposite way: I made a tool that runs ingame and allows me to spawn additional viewports to see other parts of the scene as I play. Works fine if event handling is done right :) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#19197 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEJES1dpCmR1aQ8phJQlBVAxqOs0dhSKks5uG1MKgaJpZM4UPMaZ> .

[Calinou]

There's a pull request for in-editor playback, but it's considered hacky and was thus not merged (see the comments about editor stability).

And yes, the Godot editor is technically a Godot game written in C++ 😃

[Two-Tone]

It wasn't that it was called hacky, just that reduz was justifiably worried that a crash in the running game would crash the entire editor. If that issue could be solved, I bet reduz would be more open to the idea.

[Calinou]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!