Open Mickeon opened 2 years ago
zinnschlag
commented
2 years ago However, due of its limited size, this list gets cumbersome as names get longer.
That is true. Somewhat. But it is infinitely worse when the file names are displayed horizontally, because text is wider than it is tall. If you have enabled full paths or have a really large number of files the horizontal option becomes utterly useless, even on a wide screen monitor.
Mickeon
commented
2 years ago [...] If you have enabled full paths [...]
This proposal doesn't aim to fix this issue. I suppose it's fair to say the "Full Path" option itself needs some tinkering, because it by itself isn't exactly useful, even as is currently. On top of my head, with the tabbed visualization of this proposal and the option enabled, the path could be fully visualized only when the Script is selected.
[...] or a really large number of files [...]
The mock-up is able to fit a decent amount of Scripts. Any more than that would be overwhelming not just to the average user, but to the very current Scripts Panel, as well.
zinnschlag
commented
2 years ago Guess your idea of "decent amount" is very different from mine. I typically have around 20-30 scripts in that panel. That is still kinda manageable with the current UI. Though I agree that the panel could use some improvements. Now, I don't consider myself an average user. But what you are showing in your mock-up doesn't look average to me either. It looks very low.
On top of my head, with the tabbed visualization of this proposal and the option enabled, the path could be fully visualized only when the Script is selected.
That's not going to do it, unfortunately, since the full path would be required to find the right tab in the first place.
The gripes I have with this idea are more fundamental. Horizontal tab interfaces are fine when you have a finite and small-ish number of text items. But they utterly suck as soon as scalability becomes an issue. I would rather not see Ui elements added that are only useful for casual-ish users (vs. UI elements that scale well and are useful for all kinds of users).
There was a proposal a while back (can't find it now) to also nuke the scene tab bar and replace it with a drop down menu in the scene tree panel. I kinda hope something comes out of that.
Maybe the problem of the script list panel taking up too much space could be solved by having an option to not have it permanently on the screen? It could be opened via a keyboard shortcut and function as something like the quick open dialogue, just limited to the scripts currently open.
Mickeon
commented
2 years ago Maybe the problem of the script list panel taking up too much space could be solved by having an option to not have it permanently on the screen?
That's already a possibility, complete with shortcut. The proposal mentions it, as well.
As mentioned in the proposal, the Scripts Panel is fairly crucial during development. Opening the Script Panel, selecting a Script and closing the Panel just to be able to fully see the Script can be a burden. Displaying and rapidly switching between the currently open Script and the other open ones is pretty important too. Because of this, the Script Panel is mostly always best left open at all times.
The proposed solution is a more efficient use of space for users that do not keep an overwhelmingly amount of scripts open at the same time and struggle with screen space, while still serving the core functionality the Scripts Panel has to offer. The simple proposed ability to close by clicking on the cross may even encourage users to keep the focus within reason.
Furthermore, quoting this very proposal:
The current Script Panel would still be available and toggleable as always, even with this option enabled.
Both should in fact coexist and/or be interchangeable ways to display the open Scripts, whichever way would be favourable for the occasion.
lentsius-bark
commented
2 years ago To add to this, I notice a major difference in my workflow between Godot script editor and vscode is that in Godot I often have way more scripts than I need open and rely on other ways of finding the script other than the actual side panel(quick open, alt+arrow), whereas in vscode the moment I have more than 5 scripts open I know it's time to reorganize.
My UX question here would be which of the two approaches better supports the natural workflow of a developer?
I don't have the answer but imo the answer to that question is what also substantiates the decision for this proposal
golddotasksquestions
commented
2 years ago I work on 1080p laptop monitor. The first thing I do when I open a new project is to hide this script list panel, because the horizontal space for scripting is just so much more valuable. (Which is why scripting font choice is important and should be reconsidered for Godot4)
I then navigate the scripts by clicking on the scene tabs in the top toolbar and the script icons in the scene panel. A Editor setting toggle to also make all scripts of the current this scene appear in the toolbar would be appreciated. A further Editor setting toggle to make all scripts appear in the top toolbar would also be very appreciated.
It's totally fine if the names are abbreviated in the tabs when this horizontal bar becomes crowded, so are the page names of the page tabs in any internet browser.
sosasees
commented
2 years ago if we want to show the full path in horizontal tabs, we could take inspiration from any Chromium web browser on Desktop:
Google's designers recognized that tabs barely have any space for text — especially when there's many of them, and that this can become problematic for differentiating which tab has which webpage opened. So they added a textbox that pops up when hovering over any tab.
if you use a Chromium browser, try it now: hover over any tab and you will see the full title in a textbox below the tab.
in Godot horizontal script tabs, we could replicate this to show the script's full name — and the full path starting with res:// below.
zinnschlag
commented
2 years ago So they added a textbox that pops up when hovering over any tab.
So you don't actually get the information you need straight away. You not only need to perform a time-consuming action to get the information, you need to do that multiple times and actually search manually for the tab you are looking for.
This belongs in the user interface design hall of shame. Horizontal tab bars remain fundamentally unsalvageable for heavy use (longer tab text and/or large number of tabs).
Reasonable options are: a) ensue that there are no use cases that fall into the heavy use category (or at least that they are so uncommon that you don't care about them) b) provide an alternative UI for heavy use (probably with an option to disable the tab bar) c) don't do horizontal tab bars and come up with some other interface style
Clearly some people here think option a) applies. Fine, if their workflow looks like that. But it definitely does not apply to everyone.
I recognise that this proposal includes option b). However that isn't a good solution either IMHO. The Godot team would have now to maintain two separate interfaces for the same task. And we are still left with the vertical script list in its current state and its less than ideal usability (horizontal space and such). People with less wide monitors and heavy use cases would still have issues.
Exerionius
commented
1 year ago I can't describe how many times I clicked on a tab expecting it to switch to another script, but got switched scenes instead. It's pretty hard to beat this habit coming from decades working with IDEs. This proposal feels most natural.
In the end I switched to using VS Code as a script editor just because of tabs. And even if debugging barely works in VS Code it is still worth it, just because of tabs.
winston-yallow
commented
1 year ago Now that godotengine/godot#62378 is merged this proposal feels even more relevant.
One argument against this proposal (https://github.com/godotengine/godot-proposals/discussions/4248#discussioncomment-2443724) was that it takes away vertical space. That is true, but the current approach takes away horizontal space. So adding this new layout as an option allows the user to choose what they prefer. I personally like putting my script editor on half of my monitor, with the docs webpage on the other half. So I would love to use the vertical space instead of the horizontal space.
Mickeon
commented
1 year ago I want to note something that I forgot to address as a suggestion in the original proposal.
The tabs should be able to stack vertically as well (similarly to a flex box in CSS, or Godot's FlowContainer). This is currently not possible with the current tab system that is available in the engine. Tabs can only appear horizontally, and when the limit is reached, clickable arrows appear that display the rest.
For this to work the way I envisioned it, either it is its own thing, or TabContainer would need to be able to do this (which would need to be suggested in another proposal).
Mickeon
commented
1 year ago While time passed, by the way, a few addons for Godot 4.0 that somewhat implement the proposal made the rounds:
Normally, this would be the end-all "workaround". But let's remember that editor-only addons are quite the burden to set up as they are currently. They need to be copy-pasted for every project, and tend to assume there's only one individual working on it at any given time.
Still, you could make use of these addons to get a glimpse as to what could be, if this proposal were to be implemented.
FabriceCastel
commented
8 months ago I feel like I'm missing a bit of historical/UX context here as to why:
Is this a result of limitations/legacy constraints? Or do people have some workflows I'm not aware of where they actually want to have access to these things at all times while editing scripts? My inclination is to entirely replace the scene tabs with script tabs - that's exactly what I expected would happen the very first time I switched into the script UI and was very confused when clicking those tabs changed scenes...
Mickeon
commented
8 months ago Is this a result of limitations/legacy constraints?
Not necessarily, they just have not been discussed. I for one am not against "defocusing" scene tabs to reduce clutter, to an extent. It's unrelated to this proposal though, so it would need to be discussed elsewhere.
My inclination is to entirely replace the scene tabs with script tabs - that's exactly what I expected would happen the very first time I switched into the script UI and was very confused when clicking those tabs changed scenes...
You are not the only one proposing this, I recall. It does pop up from time to time but it is not really favoured. Both Script and Scene selection intertwine between one another for various reasons, and both coexisting is kind of important for all users. For example, autocompletion results can depend on the currently opened scene. Dragging nodes and Inspector properties into the current script is also possible.
winston-yallow
commented
8 months ago @FabriceCastel my workflow depends on changing scenes while in the script editor.
It is useful for a couple of things:
Describe the project you are working on
Typical Godot game, making extensive use of the Script Editor.
Describe the problem or limitation you are having in your project
The Script Editor presents a toggleable Scripts Panel to the side listing all of the opened Scripts and Documentation pages.
For the most part it does serve its purpose. However, due of its limited size, this list gets cumbersome as names get longer.
Even with good coding practices, this is not that hard to experience. The Editor settings expose a property called "List Script Names As", set by default to "Name". With this set to "Parent Directory and Name" or "Full Path", the issue becomes glaring, rendering these two options a bit impractical.
While the simplest solution would be to expand the Scripts Panel manually, it clearly doesn't scale too well and takes a lot of valuable space from the actual text editor. Furthermore, it's quite the empty space, and it may even be less taking in account the Mini-Map, the Scene Panel, the Inspector Panel, tabulation used across the script...
For this, simply closing the panel does the trick, but the Script Panel has a crucial role during development, as it allows quickly viewing and moving across scripts. Having to toggle it constantly can be quite the burden, and it's often best to leave it open at all times, as is.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Add an option to display Script titles on a bar, as tabs, on the top of the Script editor, akin to other IDE's, such as Visual Studio Code.
The size of each of the Script titles may vary. Whatever icon is used for the Script should also be displayed to the side. Should there be not enough space to fit all Scripts in one line, a horizontal scroll bar may become available. When the Script is selected, it is highlighted, perhaps coloured the same as the Text Editor's background. If not visible, the bar will scroll to display it. When a script is selected or hovered, a cross may also become available, to close the Script without need of right-clicking or using the shortcut.
I would also suggest splitting the Scripts and Documentation into two different bars, perhaps optionally?
The current Script Panel would still be available and toggleable as always, even with this option enabled. It is useful on its own right and has potential for improvement. (https://github.com/godotengine/godot-proposals/discussions/4011) (https://github.com/godotengine/godot-proposals/discussions/4042) (https://github.com/godotengine/godot-proposals/issues/4073) I'm sure it's also something part of the userbase has gotten quite accustomed to. Perhaps the bars could easily be toggled by a button on the bottom, similar to the current Script Panel?
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
It shouldn't be exactly like this. This proposal is made under the assumption that it would visually be improved in the implementation, with better spacing and use of colour to fit the rest of the interface.
It's just to get the idea across, so to speak.
If this enhancement will not be used often, can it be worked around with a few lines of script?
... You could use other IDE's. However, it's worth noting that the Godot Editor having a built-in text editor is nothing to scoff at. Some users would even struggle to keep two programs open at the same time, whether that'd be due of management or performance issues, or even simply limited screen size. Shrinking the font size may also not be an option for them.
Is there a reason why this should be core and not an add-on in the asset library?
The Script Editor is core.
Note: see also related discussion: https://github.com/godotengine/godot-proposals/discussions/4248