Move Script List to docks

[YuriSizov]

Describe the project you are working on: Puzzle game with a lot of coding

Describe the problem or limitation you are having in your project: I work mainly on a laptop with 1080p resolution. Godot has a three-column layout, which turns into four-column layout when using the Script Editor, which limits the space available for coding. Though there are options to extend that space, they have their own shortcomings, which turn them unusable.

• Using distraction-free mode is not an option, as it limits access to the Output and Debugger panels, as well as Search Results panel. This means constant switching back and forth between distraction-free mode and normal mode.
• Hiding script list is not an option, because there is then no indication, what file is being edited and no easy way to navigate between scripts (and help pages).

I've described in great detail my concerns about current layout in regards of the Script Editor on Reddit to gather some community feedback: https://www.reddit.com/r/godot/comments/f5siu7/do_you_experience_problems_with_ui_when_using/

While I did not get much feedback, there was some show of support in upvotes. So some people are as frustrated as I am. The thing is, I find this UX/UI problem too complex to be solved by small changes, however I want to propose a small change that can actually make things a little easier to work with going forward.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:

I think that Script List is an awful control. It duplicates all functions of FileSystem dock and gets help pages as an added bonus. Though, I can see, that it is impossible to integrate some of the mechanics of Script List into FileSystem dock without furthering user confusion. So how about we:

1. Put Script List beside FileSystem dock as another dock;
2. Add a name/path of the opened script to the Status Bar of the Code Editor;
3. Somewhere down the line figure out a better place for help pages (I think they should be accessible without the Script Editor anyway).

This way, developers can put that script list in any one of the 8 places available, some event resembling its current position. Still easily accessible, it will no longer take excessive space in the Script Editor.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

Some changes to layout in script_editor_plugin are going to happen across multiple files. I've made a mock-up with a quick GDScript plugin. Here is how it can look:

Note that with additional space the error message does not normally conflict with the file path/name.

There are help pages missing in this mock-up as I did not find a way to get them listed from GDScript API. But they are going to be there, as well as a split panel with method navigation and doc navigation controls.

Here is a "before" screenshot for comparison:

If this enhancement will not be used often, can it be worked around with a few lines of script?: It can be partially turned into an editor plugin, as I was able to do this mock-up "in engine". However, I feel like this can improve overall user experience going forward, and is not the only step to improve in regard to listed concerns.

Is there a reason why this should be core and not an add-on in the asset library?: See above.

PS. I can work on the implementation myself, if needs be. Seems within my knowledge of the project.

[golddotasksquestions]

I believe part of the 4.0 intended changes is going to be freely moving and docking panels. But I haven't heard news about that in a while. Not sure how far this is or if the script list is considered it's own panel, but I sure would hope so.

[YuriSizov]

@golddotasksquestions Well, currently it is absolutely not a panel that can be easily extracted, layout-wise. So even if some sort of rework is being done, it needs to be separated in code anyway. From what I understand of the proposed changes for 4.0, it's likely that the whole Script Editor view is going to be detachable.

[rainlizard]

+1 for any changes, I'm not a fan of the Scripts Panel at all, it's always in the way and the "Toggle Scripts Panel" button is annoyingly not remembering to stay hidden when you restart Godot. There are so many ways to open scripts: FileSystem, ScriptsPanel and SceneTree, having this many ways should not be a priority over screen space, Godot can feel awfully crowded at times.

Making the Scripts Panel dockable is a step in the right direction.

[Leleat]

Instead of doing it as a dock, I suggest doing it like other code editors (for ex. VSCode), where each script gets their own tab. Currently only scenes have tabs and you need to switch to a (dedicated) script editor while having a scene open (even if that script isn't attached to that scene). Scripts, which are attached to a scene could still be grouped with the scene tab to avoid clutter, but non-scene-attached scipts should have their own tab.

Having a keyboard shortcut to cycle through the open tabs and to search for an open tab would also be immensely helpful.

[YuriSizov]

@Leleat The thing is, Script List is tabs. It's just a vertical layout. I think it was horizontal, like you expect from a code editor, in previous versions of Godot, but changed to this at some point. Still behaves like a set of tabs and uses TabContainer internally.

Due to how Godot Editor is composed, script tabs were separate from scene tabs. Which is probably why they were changed to a vertical layout, to reduce confusion. I'm not sure it would be a good idea to mix scene and script tabs together, either, even if internals change to support it. People who tend to open a lot of scenes and a lot of scrips will be overwhelmed quickly. Though, I don't know how do you envision grouping related scenes and scripts, it might work if done smartly. Personally, I wouldn't want to look for a scene to find its script and would prefer to be able to look for a script directly.

I'm not sure about scene tabs, but I think there are shortcuts to move between open scripts. Wouldn't be hard to implement regardless.

[Leleat]

@pycbouh if someone has a lot of scenes open, they can also get overwhelmed. Just adding scripts which aren't attached to a node as a dedicated horizental tab shouldn't add that many more tabs.

By grouping I meant that if a script is attached to scene/node that script shouldn't get a dedicated tab but be opened at the scene tab (like it is now). Switching between the script and 2D/3D view can happen like it is now with the F-keys.

If that is still an issue; a keyboard shortcut like ctrl+tab to cycle through scripts and ctrl+e to get a pop-up to show all open scripts (like the current scripts list but as a pop-up) could be useful to get an overview and navigate quickly. Currently there is only a way to quick-open scripts/scenes. But that gives you a pop-up of all available scripts/scenes.

[golddotasksquestions]

What confuses me a lot, is the fact that all scripts are available in the script list at all times, but when clicking on a script of another scene, the active scene does not switch to the scene that houses the script.

I would expect the script list to only show my current scenes scripts. This would make the script list also a lot less confusing if it would be horizontally oriented in tabs underneath the scene tabs.

[YuriSizov]

@golddotasksquestions I would agree with that flow, if only it would not make opening the script I need a two-step process (Open the scene that holds it, then open the script). Though, if each scene would hold its own list of scripts (with no regard to those scripts actually being attached to the scene or its nodes), then maybe it could work.

[golddotasksquestions]

If we had freely dockable panels you can close or open from the drop down menu, like any other respectable editing software, I suppose it should be easy to open a script panel that shows all your scripts or just the ones in your scene. Maybe there is also a checkbox to make it a horizontal tab like bar, or a vertical list. Maybe there is a small cogwheel icon in the corner of that panel that allows me easy and direct access to these settings. Maybe we stick with the meaningless 3 dots.

[Zylann]

One thing that annoys me with a dock containing open scripts, is that with the way docks work now, it would be constantly shown. I don't always need this. I can click on a neighbor tab to hide it, sure, but then when I open the Script editor I have to also tab the script list back. And also find a proper dock to place it, because that dock will then hide if I want to show the list back. And since the script list + function list often reaches total monitor height, it would hide a dock similarly sized, of importance then... On extra note: VisualScript even needs that left panel to show information that is otherwise visible nowhere else.

Also, as said earlier, that list is tabs, a concept found in all code editors now, which is expected to be seen when the script editor is seen. In an engine that deals with so many other things, putting this in a separate dock makes it look like something functionally separate. For discoverability, it would even need to be visible by default, and it's also where you can see the name of the current script.

If the problem is about running out of space, going for a dock surely optimizes it a bit, but it's a bit too much of a change, unless maybe it is somehow made an option (cuz well, I like the way it is currently heheh). But once the script editor can be popped out in its own window, I feel there won't be any need for this workaround anymore. No wonder it gets asked so often. I also have 1080p. There are other areas of the editor which terribly lack of space, but not much can be done about them without a more flexible layout or multi-windows.

That said, with the specific layout you posted on reddit, the script list on the bottom left could work well, when disabling the function list. But then I don't know about other kinds of layouts, and there are valid points mentionned earlier in the cases where the script editor isn't open.

[rainlizard]

with the way docks work now, it would be constantly shown. I don't always need this.

You could have it show/hide automatically the way it does now - except within the docks. One benefit of this would be the customization of being able to choose which dock you want to be hijacked. So if it's on the Inspector dock the Inspector will be tabbed (automatically). If its on the FileSystem dock, the FileSystem will be tabbed. If it's in its own dock then it will look and behave exactly as it does now. Don't forget there are 8 dock slots.

If implemented like this, this feature wouldn't remove any functionality, only add.

[Zylann]

Right now the only layout that I like including this feature is @pycbouh 's screenshot, with the script list on its own dock below the file system, assuming clicks inside would open the script editor if not visible. It would reproduce a decent layout like VSCode or QtCreator, where tabs are always available on a left panel.

However, there may be 8 dock slots, it's still the same screen space to fill. It adds functionality but by stepping into an area that introduces different behaviors (but only with the current system, we'd need to change it). What would happen to the function list? I noticed Visual Script uses this space for the list of members, which is not shown anywhere else. With the script list it easily tops up the screen. Or maybe the function list shouldnt be part of the dock move, I don't know.

You could have it show/hide automatically the way it does now - except within the docks.

That's interesting. It would need to be a change to the dock system though, where docks can be told to show/hide depending on which main screen is visible. That's actually what happens in Blender with the docks, or in QtCreator and VS when debugging.

[YuriSizov]

@Zylann

And also find a proper dock to place it, because that dock will then hide if I want to show the list back. And since the script list + function list often reaches total monitor height, it would hide a dock similarly sized, of importance then...

You can put the dock in the left column, in the right-hand dock, and it will arguably be the same as before with a small effect on the bottom panel.

One thing that annoys me with a dock containing open scripts, is that with the way docks work now, it would be constantly shown. I don't always need this.

Yes, there is a point, that it will be always accessible. In some cases it is a great addition, as you can go directly to a specific script at any time with any main view open. Then there is the problem, that being no longer tied to the script editor it can be hidden even when needed the most. You may not always need this, but that can be argued about a lot of UI elements currently easily accessible. As I mentioned before, sometimes UI elements don't make sense and provide confusion, even. Like, scene tabs.

If there is a real concern about the dock not being handy, then there must be a compromise how to make it not annoying and yet accessible.

Also, as said earlier, that list is tabs, a concept found in all code editors now, which is expected to be seen when the script editor is seen. In an engine that deals with so many other things, putting this in a separate dock makes it look like something functionally separate.

But in code editors you don't have two lists: filesystem and opened scripts. When configured as tabs you actually have two distinct ways to interact with files. But what we have now in the Godot Editor is two similarly looking and functioning lists of files. It just looks wrong.

I'd argue, that script editor should be separated completely from concepts it is currently bound by. It should not depend on selected scene and be limited by main view selector, fighting for space with previews and ancillary tools. But I do not have a solution to how change things properly. For now I can only offer a small change, that already made my life better, after I refined the PoC plugin a bit.

But once the script editor can be popped out in its own window, I feel there won't be any need for this workaround anymore. No wonder it gets asked so often.

Pop out can only help those, who have two monitors. If working on a single monitor or a laptop without external monitor, what would pop out achieve? Alt-tabbing between windows is hardly more user friendly. To that end I can have two Godot Editors open right now.

That said, with the specific layout you posted on reddit, the script list on the bottom left could work well, when disabling the function list. But then I don't know about other kinds of layouts, and there are valid points mentionned earlier in the cases where the script editor isn't open.

That specific layout if the default layout and that is why I used it. My layout differs greatly. But the beauty of the dock is in the fact, that it is adjustable. Script list is not. It is fused into place and takes too much space, while acting like FileSystem dock and keeping active script name to itself.

Edit: If you were talking about my initial post on reddit, where I actually used my layout, then I'm sorry, that I've got confused.

For discoverability, it would even need to be visible by default, and it's also where you can see the name of the current script.

Actually, the fact that script list is the only place to display the name of the script is my initial point, and I added it to the Status Bar, as per my suggestion. It is a bit weird place for a file path, but this way it does not take any more space. If help pages are moved outside of script editor, there will be some space available in the top bar, which is probably more appropriate.

What would happen to the function list? I noticed Visual Script uses this space for the list of members, which is not shown anywhere else. With the script list it easily tops up the screen. Or maybe the function list shouldnt be part of the dock move, I don't know.

I thought about keeping the member list where it is right now, and only moving the file list itself to a dock. I'm fine with that, as I personally don't ever use member list and have disabled it, but that separation may be hurtful to some, or seen like a half-measure.

PS. Here is what my layout looks like:

[Zylann]

UI elements don't make sense and provide confusion, even. Like, scene tabs.

Scene tabs actually have a big impact on a lot of things in the editor that are not directly the scene editor itself. It affects what the scene tree shows, which scene the Play Scene button will run, and extra auto-completion of paths and types in the script editor. Also by default, Ctrl+S saves that current scene, whatever main screen you have open.

But in code editors you don't have two lists: filesystem and opened scripts

Typo?

But what we have now in the Godot Editor is two similarly looking and functioning lists of files. It just looks wrong.

I don't think they are much different than what's in code editors. Maybe they look like that because they were added similar functionalities? One shows only open folders, needs double-click, shows more than just scripts, not only those open and doesn't includes docs. The other shows open scripts which get shown in one click. Also I kinda agree docs should not have been placed there, if placed at all.

I'd argue, that script editor should be separated completely from concepts it is currently bound by. It should not depend on selected scene and be limited by main view selector, fighting for space with previews and ancillary tools.

It is fairly independent already, it litterally fits into one single control, which means it would be easy to move it anywhere else (having a dock would mean two controls though). Also it still has a bit of talking with the current scene, but mostly for extra assistance when context is available. But yeah, in terms of space it can be a bit cramped.

Pop out can only help those, who have two monitors. If working on a single monitor or a laptop without external monitor, what would pop out achieve? Alt-tabbing between windows is hardly more user friendly.

It means the script editor is still only one click away while being able to give it any desired size. But I see what you mean, the experience would be a bit different.

That specific layout if the default layout and that is why I used it. My layout differs greatly. But the beauty of the dock is in the fact, that it is adjustable. Script list is not.

I agree, but removing this problem puts in another, which needs solving by improving dock functionality. Now that I figured it out, I'm not really opposed to this.

[YuriSizov]

@Zylann

Scene tabs actually have a big impact on a lot of things in the editor that are not directly the scene editor itself.

I did not expand on the subject to keep the long reply brief, but it was a reference to something I had talked about in the initial Reddit post. Scene tabs are perfectly fine for scene manipulation, but they make little sense for any editor view that is not 2D or 3D preview. In Scripts they only affect the node path autosuggestion feature, which should not work that way anyway. In AssetLib they are useless, as they probably are for a lot of 3rd party tools placed in the upper tool selector (Translations and Game Editor in my case).

Granted, you may want to change your active scene at any given moment, but that does not reduce confusion from having scene tabs above the Script Editor. It looks like they should at least switch scripts, or maybe each scene should have its own script list that changes. But currently they don't actually switch any scripts, when you click on them, even though their UX suggests that they should.

Typo?

No, no typo there. What I was saying is that in code editors there is a distinction between a file list (in some file system panel) and a set of opened files (in form of tabs). Godot Editor uses the same UI for both of those, while also having tabs for scenes above the Script Editor. I don't know, how people unfamiliar with coding see this UI, but it takes a big tall on me, as experienced programmer, how worked many years with different code editors.

And I find it universally confusing from UI/UX standpoint anyway. Turning tabs into a list is okay as an option. VSCode, for one, has a list of opened scripts alongside the tabs, so it can be filtered and sorted. But in Godot Editor it is the default UI, and it mimics functionality from the nearby FileSystem dock. Why do both of them have filters? Can't FileSystem panel have a switch to show only scripts, and thus provide the same functionality within one singular UI? Why have a list with manual sorting, when lists are usually read in alphabetical order? Sure, tabs are rearrange all the time, but it makes little sense for lists. FileSystem dock does not allow rearranging, does it?

And that's the thing. If it looks like a list, but does not work like a list, when why is it a list? I've never used Godot Editor when these were tabs, so I have no idea how confusing it was to have tabs for scenes and separate tabs for scripts, but it feels like what we currently have is a bad way to fix the initial issue.

---

That said, at this point I'm not trying to improve overall UI/UX with my suggestion. I have no clear vision, how that Swiss army knife of the editor that is Godot Editor can be handy for every type of person. Some tools are at arms length, some are just shoved into the bottom panel when there is no place for them in any other part of the UI. And it is hard to know how exactly is the editor used. Rare GitHub issues on particular usability problems are not indicative.

There is also a point, that with 4.0 and the possibility of pop outs and such UI can be adjusted in a different way than before. We may be getting closer to a fully customizable UI, like in one of the JetBrains' IDEs. So there is little point in debating big changes before that happens.

Which is why I feel like my proposal is good, being, in my opinion, a small adjustment for those, who are already comfortable, while allowing more space for those, who are confined by their work environment.

[Leleat]

I noticed that Godot can already show the current script's file name in the menu bar but decides to hide it (for some reason). So there is no need to add it to the status bar. Here is how it looks (I've changed it to display the file path though):

I've also made an example of you could manage the scripts and docs. I split them up and moved them into seperate lists and limited the docs list to the 4 most recent searches. Right now I need to "manage" the docs and close them constantly, otherwise they pollute the scripts lists. I'd also like the option to hide the scripts list only (right now I can only hide the method list or the entire script panel) like this:

@pycbouh What do you think? I feel like, if you could toggle the bottom panel in the distraction free mode (see my screenshot, I added a toggle besides the distraction free mode button), most - if not all - your original problems would be solved, no?

[YuriSizov]

I noticed that Godot can already show the current script's file name in the menu bar but decides to hide it (for some reason).

That reason may be the lack of space in the top bar. It's not noticeable in your examples with DFM enabled, but it is a problem without it. As I mentioned, if Help is moved outside of Script Editor, the current file path can take its place easily.

I've also made an example of you could manage the scripts and docs. I split them up and moved them into seperate lists and limited the docs list to the 4 most recent searches.

I don't know, what this solution accomplishes. There are now 3-4 lists in that one column, and you arbitrary decided to limit the number of open documents to 4 to reduce the impact of this change. At the end of the day, I just don't think, that help should be integrated into this tool. It should be globally accessible. Since we have to switch between a script and a help view anyway, we might as well put it into a dialog window and list recent docs there.

I added a toggle besides the distraction free mode button), most - if not all - your original problems would be solved, no?

While it may please some, myself included, I feel that this addition defeats the purpose of the mode. Frankly, I don't see a reason for such mode in a multipurpose editor at all. In code editors you hide ancillary tools with it, so you can concentrate on your main purpose — coding. Here, in Godot Editor, you hide everything, most of which is equally important to the tool that is left on screen. Why would one want to do anything without access to the scene tree or the inspector? So I'd rather we have a solution, that optimizes space in normal mode, than make DFM more pleasant for a particular use case.

[rainlizard]

@Leleat If you're positing distraction free mode as the solution to this crowded UI issue, then the conversation is shifting away from the original subject that this thread is about.

Distraction free mode is an entirely different conversation that has it's own numerous issues (basically it's not convenient enough). It doesn't fix the problem here.

[Leleat]

Well, you could generalize my suggestion of using DFM into "main screen profiles". Godot already allows to seperate the DFM (for example: auto-activate the DFM when entering Script view and auto-switch back to "full view" when entering 2D view).

Combine that with the option to allow the user to decide what docks get hidden in DFM and what is kept (like I kept the bottom panel above) and you have workspace profiles, which seem easy to implement with the current state of Godot.

For example: show scene tree and node tab + bottom panel in Script view and everything is shown in 2D or 3D view.

[YuriSizov]

@Leleat Having predefined profiles for several possible scenarios, that switch automatically, might work.

[avril-gh]

PR https://github.com/godotengine/godot/pull/38351 does not implement all the ideas discussed here, but meanwhile, aids the ones who are tired of never ending closing scripts panel without end after project reopens to free some space for code.

It remember visibility state of scripts panel and preserve it between project sessions. So if you close it - it stays closed even after reopening project until you manually open it again

[Loregret]

@pycbouh Is there any chance of implementing this?

[YuriSizov]

@Loregret I can implement this, yes, but I'm not sure what the stance of the rest of the editor maintainers on this is. I have quite a few tasks in my pipeline at the moment, but I can discuss this idea again with the team when I am a bit more free.

I can also give a bit more polish to the bespoke plugin I've made those years ago and release it publicly. It doesn't have support for documentation pages (because there is simply no API for it), and I didn't replicate all the features, but it was enough for my own purposes.

[Loregret]

@pycbouh I got you. Thank you for reply. I hope to see plugin of yours, someday. Let me know if there's any progress on this issue.

[Calinou]

For the record, this feature looks good to me (at least on the mockup). As long as the existing keyboard shortcuts to navigate between scripts are preserved, this should work well enough.

One downside however is that once this is implemented, the distraction-free mode will now hide the script list (it currently doesn't). That said, there will be less reason to use distraction-free mode only when scripting since you will have much more horizontal screen real estate available in the first place.

PS: For future reference, this has been resolved since Godot 3.3 by ensuring the bottom panel is always visible, even when distraction-free mode is enabled:

Using distraction-free mode is not an option, as it limits access to the Output and Debugger panels, as well as Search Results panel. This means constant switching back and forth between distraction-free mode and normal mode.

[YuriSizov]

For the record, this feature looks good to me (at least on the mockup)

You can give my plugin a go which implements this roughly (albeit with very limited functionality): https://github.com/YuriSizov/godot-editor-scripts-dock

[dugramen]

I made a plugin of this a few days ago, and it just got approved in the asset library. It moves the entire left panel to a dock, and everything works surprisingly well.

Here's the link https://godotengine.org/asset-library/asset/2680 And GitHub repo https://github.com/dugramen/godot-script-dock