All the weird things with godot

[jeancallisti]

Godot version

3.4.2 stable

System information

Windows 10

Issue description

This is an exhaustive list of counter-intuitive things with Godot UI. It will grow with time.
The kind of things that confuse the newcomer and make them hate Godot before they even get to like it.
The kind of things that smell like "Blender UI" before they fixed it (if you remember the old days)

Fix it or not, I don't care, but don't say that no one warned you :

1) Position of "Asset library" button.

the asset library button is next to the "View" buttons (2D, 3D, Script).
Conceptually, those other buttons are meant to let the user choose under which "perspective" they want to see the asset (most often, the scene) currently open: Do they want to see it as a 2D thingy? A 3D thingy? A text? etc.
And then there's the Asset Lib button, which has nothing to do with any of that. the Asset library button is meant (conceptually) to be used on a global level and applies to the whole project.
So why is it hidden there? Why is it not with the project settings? Or above the FileSystem panel? Or in the top menu? Etc. Mystery.

2) How the asset library opens

The asset library appears in a tab, but... Not in its own tab.
It steals the tab of whatever asset was currently open.
Worse, it does not rename the tab. It still seems like my asset is open but the tab wears its name, except it now displays a list of assets to download instead.
Now I can't close the asset library without closing my own asset. I have to do the awkward thing of remembering how I was currently displaying my asset (2D? 3D? script?) and click on the corresponding button to bring it back how it was.
Shoo! Get your own tab, asset library!

2bis) How literally anything opens

Everything and anything steals your currently-open tab. Including the help! Absolutely maddening.

3) When a new scene is created, it's not really created

So I go to the FileSystem panel and right-click on a folder, then "new scene". A popup appears to let me enter the name. I click OK.
Aaaand... the scene has not been created?
I mean : Nothing changed on the screen. Nothing appeared in the folder (!). And no new tab appeared.

Upon closer inspection, the tab that was currently open is now titled "empty". What the hell does that mean.

As you've understood by now, I'm acting naive, but no one (and I mean, no one) could guess that you're now supposed to create a root node before you can even save the scene and see it appear in its folder. For any normal human being, if you click "OK" then the scene is supposed to have been somehow created.
At least, make the new scene appear in its own tab instead of stealing the tab currently open (it looks extra awkward if you were currently displaying the Assets library!)

4) How do I close a project?

In every app in the world, in the top menu, the leftmost menu is for the app itself -- or at least the main, biggest entity (usually, the project). Then you have other menus, more to the right, for other smaller things.

Not in Godot : The scene is leftmost and the project comes second.
So when you want to close the project, it becomes awkward. If you're a beginner then you need to remember that the "Scene" is not the boss here. It's not your project. The project is your project. And even when you click on that menu, there's no "Close" entry. It's awkwardly named "Exit".

5) Rename : Never the same number of clicks

• In the scene hierarchy, double-click to rename
• In a SpriteFrames resource (bottom panel), single click on an animation in the list of animations
• In the FileSystemPanel, clicking doesn't rename. You need to right-click-->Rename

6) Clicking outside of a dropdown menu actually does click

• Go to the inspector
• Expand any property that has a dropdown.
• Click outside of it, for example just on the right of it to exit (that is, collapse) it again
• Oh noes! It turns out that the area just to the right of it was the "delete" button. By collapsing your resource you deleted it.
• that's because in most UIs, clicking outside of a dropdown makes it lose focus, (but doesn't actually do the click wherever you clicked). In godot it does!

7) No shortcut to open the help page of a native function (?)

• Open a .gd script
• Highlight any native function name (e.g. highlight word "printerr")
• You can't press F1 or whatever shortcut to display the help page
• You have to press F1 and then type again printerr to find the help page (if it exists! Can't know for sure until you've done that)
• Some people have pointed out that Ctrl+click can help. Well, yes, but only if you click on a clearly-defined token (e.g. , an enum value). For example, I had to search the help to find that "Label.text" is incorrect (and "Label.set_text" is correct), because there's no direct Ctrl+click on the word "text".

8) No shortcut to teleport to function definition

• Create a new .gd script
• Create local function. for example _func myFunction():
• Somewhere else in the same file, write a line of instruction that calls function _myFunction
• highlight it
• No shortcut to go to _myFunction 's definition (for comparison: you'd press F12 in Visual Studio). If you don't know where that function is located then you have to do Shift+Ctrl+F to do a full search on it every time.

9) There is no "Edit" menu

• Every application in the universe has an Edit menu with the options "Undo", "Redo", "Cut", "Select all"...
• Not Godot. You're supposed to know that the shortcut is Ctrl+Z, Ctrl+Y...
• ...Which is EXTREMELY confusing, because A) Some applications use Ctrl+Shift+Z for "redo",
• and B) in my case Ctrl+Y doesn't even work after I change the size of a Rect. I can Ctrl+Z, but not Ctrl+Y or Ctrl+Shift+Z. I have no idea if it's by design or not.

Don't tell me you've outgrown the Edit menu. Even the bleeding-edge Visual Studio Code has it.

10) The "navigate back" and "navigate forward" buttons are hidden.

• Look at your favorite web browser. The "navigate back" and "navigate forward" buttons are at the top left
• Not in Godot. Those two buttons are hidden in the Inspector panel.
• This makes it seem like the navigation only applies to what's inside that panel... Which is not true, as those buttons let us navigate what nodes were highlighted in the left panel (scene tree)

11) It's very hard to see what just got cancelled with Ctrl+Z

The console says stuff like "set margin_top" but it doesn't say on which node. And there's not brief visual flash on the property which value just changed.
This makes the "repeatedly press Ctrl+Z/Ctrl+Y to decide if we like the last change" workflow quite dangerous.

[miv391]

8. No shortcut to teleport to function definition

Ctrl + left click jumps to the function definition. Sure, it would be nice to have this also in the context menu.

[azur-wolve]

also 7.

Ctrl + left click → sends you to the API page of the native function / variable / class

[ssokolow]

I actually proposed a solution for "7) No shortcut to open the help page of a native function (?)" two days ago without being aware of this.

As for the rest, I've got a bunch of stuff once I'm more awake to tidy it up.

("1) Position of "Asset library" button." and "2) How the asset library opens" are part of a bigger problem with how the two tab bars and the de facto tab bar that is the script sidebar interact that I was going to title "Inconsistencies in Godot UI impede forming an intuitive navigation model".)

As a preview, I found it extremely confusing and disorienting that opening Help is treated as viewing another script within the same node, rather than as a separate "app" the way it would be with gVim/Gedit/Kate/etc. vs. Firefox/Chrome, be it "app" in the Godot sense of the 2D vs. 3D vs. Script vs. AssetLib feeling like an analogue to the desktop taskbar or in the "KDE Konqueror with KPart-based preview" sense of opening a new tab in the lower tab bar... especially when the rules for whether switching node tabs while in Script view updates what you're looking at are so difficult to intuitively figure out.

[ssokolow]

Things have been messy and distracting and I haven't had time to do a proper analysis to get to the root of what I noticed and propose solutions, so, to make sure people can get some benefit out of what I wrote, even if it may have misidentified the causes, here's the "talk to the page to get the thoughts flowing" draft/scraps I had.

It's partly a raw "in the moment" experiential user story (the lower part) and partly a half-done attempt to drill down into why I reacted the way I did and how that relates to UI design principles and conventions (the barely started top parts), so please recognize that I'm not arguing for a specific solution or even being certain that I've identified the problems correctly... just sharing my first impulsive reactions in case the insight might be useful to someone.

OK, this is going to be a long one, and a lot of what I finally understand of Godot's design was learned by accident while trying to pin down what I was describing to post this.

(I recognize that this should be split out into multiple things, but they're interconnected enough that I thought it best to start a discussion to figure out where the splits should be first.)

---

Humans like thinking in hierarchies. (And, with everything from dominance hierarchies being common in animal socialization to the fractal structure of plants, it's not hard to see why we'd have such a predisposition.)

---

Also, while there is a lot I'm complaining about, it's of the "because I care and want this to succeed" variety.

Also also, it's going to be a little bit rambling at times, because I'm trying to communicate my state of mind that makes change so essential... and how, the more actively I tried to consciously build a model for how Godot's UI navigation works while writing this, the more emotionally distressed I found myself.

In the interest of trying to manage the complexity a bit, here's what I've managed to tease out of it the full version so far, though I can't be certain I've gotten everything:

1. It's confusing to have three tab bars (two horizontal and the de facto vertical tab bar with "Filter scripts" at the top) that don't exist in a hierarchical relationship and which sometimes change each other and sometimes not.
2. It's confusing to have two sets of back-forward buttons which can change things beyond what you intuitively expect them to (eg. Browsers never switch tabs when you click Back or Forward)
3. It's confusing to have Back/Forward not be perfectly symmetrical, in that the Inspector's Back/Forward buttons can pull you from Script to 2D when you click Back and then not return you when you click Forward.
4. It's confusing to have the tab bar for nodes sometimes remember the script being viewed in each tab and sometimes not, depending on some kind of hidden per-tab status field. (Whether the last thing you did to change the script being viewed in it was click the Script icon on a node in the Scene tree)
5. It's confusing to have things like materials and the tileset objects (stuff like the collision and occlusion data which isn't part of the image itself) exist in limbo, appearing neither in the Scene tree nor the FileSystem tree
6. It's confusing to have things that don't appear in the Scene tree when it's also unclear whether Godot thinks they're in the FileSystem because they're being referenced by something else or just because it's assuming you'll be doing something it can't see with them, like dynamically loading them at runtime using GDScript.
7. It's easy to overlook the Orphan Resource Explorer or feel that you don't trust that you're using it correctly because of how disconnected the top-level of the project hierarchy feels compared to the intra-scene hierarchy.
8. The fact that .tscn files are so important as to be the root of the Scene pane, which easily becomes the center of your navigational world, yet are placed on equal footing with everything else in the FileSystem view makes me feel uneasy. (As if the official way to launch Godot and open a project were "Go to <project_root>/resources/metadata/project.godot in your file manager and double-click it".)

---

For context, I'm a programmer with over two decades of experience under my belt and an interest in UI design, but also someone not exactly that in touch with his emotions... so when I talk about some of these points, take them in the context of someone who's feeling a little stunned at how much "small, inexperienced, novice, and lost" emotion Godot managed to evoke in me without my notice despite that experience building and navigating complex UIs.

In short, Godot's navigation feels like a mess of three overlapping "tab bars" that interact in unpredictable and confusing ways, when the user intuitively expects them to have some kind of hierarchical relationship to each other, made worse by a mismatch between where Godot's UI draws the line between different "apps" and where the ecosystem at large does.

(I think the sense of distress is that, the more I thought about it, the less applicable my comfortable intuition from for navigating complex, semi-opaque systems like filesystems and websites was.)

The funny thing is that, while not the most fundamental example, the one I found most confusing and frustrating until I finally noticed something I'd overlooked while writing this is the help system.

It all comes down to how, on an intuitive level, I expect certain functions to be separate "tools", even if they are built into the same binary and UI for integration and cross-referencing purposes.

For example, for the longest time, I'd open up the Help... then look to the horizontal tab bar above the view, see no way to return to the script I was editing, get frustrated, and wind up clicking back to the script using either the Script icon in the scene browser or the script's name in the sidebar topped by "Filter scripts" completely missing that the help page had been added to it because it's intended to function as a vertical tab bar.

The presence of a horizontal tab bar, combined with my preconception that a monospace, syntax-highlighting, editable code view and a read-only, proportional-font, rich-markup, hypertext help viewer are different "applications" blinded me to that.

Then, I later discovered (and forgot and discovered again multiple times) that the Back/Forward button will switch out of help back to the document and that, if you haven't clicked any hyperlinks, it's less cognitive load than remembering which Script icon to click to get back to the script I was working on, so I started using that.

I thought it was "insane and idiotic" to have something that's conceptually a web browser switch tabs when you click Back/Forward, but that's life.

Given that 2D, 3D, Script, and AssetLib are in tabs up on the top, it feels like Help should be up there too, since it's a different "program", similar to how Blender and Vim and Firefox are different programs or how every Windows and KDE and GNOME application since at least Windows 3.1 either had its help viewer as a separate application or designed its integrated hypertext help along the same conceptual lines.

Long story short, until I was forced to look and think deeply on this, to puzzle out the UI design so I could try to separate design from accident and make suggestions most likely to be received well, I was so disoriented by the confusingly overlapping scopes of the navigation elements that I would be blind to having something like Vector2 in the code editor sidebar and would flip back and forth between my source and the help by clicking the Script icon on my Player node to get to the source and hitting F1 and re-typing vec<Enter> every single time I needed to flip back to the reference.

I do vaguely remember noticing once and then working from there, but then I took a month or two off from playing around with Godot and was back to being blind to that detail.

Another related problem manifests itself with things that add themselves to the lower pane, like the Shader and TileSet tabs, where I keep inefficiently flipping back and forth by clicking the node in the scene tree and then clicking whatever entry it is in the Inspector field because what I really want is the Node's properties in the inspector while still having the Shader or TileSet tab open in the bottom, and I can't find a way to pin the inspector to the Node while opening the lower pane.

I thought that maybe unchecking "Open Resources In Current Inspector" would change that, and it was just a case of confusing defaults but, apparently, no luck.

While I understand and agree with not exposing the TileSet in the Scene tree as a child of the TileMap, imagine for a moment if it was. Then, at the very least, I'd be able to intutively flip back and forth between the TileMap and the TileSet by clicking back and forth between a parent and its child.

...though I will say that things like Materials and Shaders and TileSets and the like have a "confusing and scary" feel to them because they feel like ghosts in the system. They're in neither the Scene tab nor the FileSystem tab. It's like files without application launchers in Windows 3.1. (You know they exist, but you have no idea how many are lurking or how to inspect them. They feel untethered from your semantic model of the project.)

...sort of like pages on a web site that you need frequently that belong to sections of the site that aren't even in the Site Map, so you have to select some adjacent section, then click an unassuming hyperlink to get to this whole other section of the site.

I think it's all down to how it's always a bit jarring to click something like a Tile Set or a Shader and, instead of having a sub-pane expand in the Inspector, the main view and bottom pane change completely, yet the scene tree and top two tab bars remain completely unaffected.

It's a reminder that there's no "address bar" or other single thing you can trust to always unambiguously tell you where you are in virtual space and provide a means (even if it's just copy-pasting a URL) to feel confident in your ability to return to places you've been.

I only noticed while I was writing this that the "overpowered" Back/Forward pair hadn't vanished just when I actually needed it, but merely moved from the right end of the main panel's toolbar to the top-right corner of the Inspector... I could have save myself so much mental effort acquiring and clicking "TileMap" in the Scene tree to go one way, then "TileSet" in the inspector to go the other way if I'd noticed that.

(Also, you can't trust that Back/Forward to be overpowered enough because it'll confusingly yank you out of Script into 2D when you click Back but then not put you back into Script when you click Forward.)

Stepping up a level, let's look at something I've sort of gotten used to as "the way of the world", but is also kind of the root of the problem... the 2D/3D/Script/AssetLib tab bar.

(Generally, I find that, once I've turned it down to just 2D/Script to avoid visual clutter from things I don't touch in my current projects anyway, its behaviour is "complex and subtle" enough that I wind up just ignoring it and letting the switch between 2D and script occur as a side effect of poking at the Scene tree.

Speaking of which, one thing I remember being a problem from the very beginning is how my intuition is affected by having multiple top-level scenes. You only ever see one top-level scene at once in the Scene pane, but the FileSystem view is called the "FileSystem" view, not the "Project" view. Intuitively, I'm always left feeling uncertain about where "In the project but just a random file with no special meaning" ends and "Recognized as something Scene would display if the root of the tree were just one level higher" begins.

...not to mention, because I know that my Tileset_gallet.png doesn't contain all the metadata I've keyed into the tileset object, the absence of that tileset object in both the Scene tree and the FileSystem tree contributes to that sense of some of the project's components being ghosts, disconnected from reality and floating uncertainly, neither here nor there. (Could we perhaps get some kind of "Resources" tab that contains things like materials, tilesets, shaders, etc. which aren't part of the scene tree but also aren't "objects that are orphans unless your GDScript is going to load them at runtime"?)

...actually, that's another point of anxiety. The Orphan Resource Explorer is tucked away in a corner of the Project menu when it feels like it should be more integrated with the FileSystem tab and more discoverable.

(Also, it'd be nice to have some kind of "Add Note" option in the context menu to be used for things akin to # Used by load_runtime_assets() in foo.cpp.)

As far as overall UI structure goes, because 2D/3D/Script/AssetLib is in the menu bar, and a menu like "Editor" or "Help" will almost inevitably straddle the division between the top of the Scene/Import pane and the main view, intuition says that 2D/3D/Script/AssetLib is a tab widget with everything below it being in its content pane and, thus, it should at least conceptually be switching the scope of everything below that row including the panes, even if the actual widgets aren't getting swapped out.

It's similar to how, barring people like the GNOME project who apparently designed their conventions and HIG without reading up on established HCI research first, the "Edit" menu in applications with an "Edit" menu is intuitively document scoped and, thus, should not contain application-scoped actions like "Preferences..." even if you are technically editing preferences.

I'm split on having "Quit" at the bottom of "Scene" for this reason. "Scene" does feel like the "File" menu and we're used to having Quit in a long "File" menu which is the left-most menu, but having "Quit" in the "Scene" menu feels like it could exacerbate confusions and misconceptions initially created by having the Scene tab designed in a way where it feels like the root of a single scene is the root of the whole project until you Just Know™ to open up another .tscn file in the FileSystem view.

Would it be possible to somehow adjust the navigation so that it doesn't feel like each scene is a disconnected little sub-project with the top-level project getting neglected, and the only thing that glues it all together choosing to put player/player.tscn on the same footing (or, actually, worse since it's in a subfolder) as icon.png?

(It may also be beneficial to expose the Project Settings dialog as a file in any such "Project pane" since the relationship between it and the Inspector has a similar disconnect to the relationship between opening scenes and opening nodes within scenes.)

After all, everything else in the Project menu is tools. It's strange and counterintuitive to only expose the project options there when everything else is reached by choosing something from the Scene view and then using the Inspector.

All this non-orthogonality between the 2D/3D/Script/AssetLib tab bar, the scene tab bar, the scene tree, and the de facto vertical tab bar on the left of the script editor is like a cognitive version of This <b>is <i>malformed</b> HTML</i>.

For example, how, if I'm looking at a Node, and then I click the icon for its script, the inspector will change... but then if I click the 2D tab, I'm left looking at the contents of TileMap and the inspector for TileMap.gd.

(This sort of thing is why I use those as a last resource and treat the Scene view more like how I treat the tree view sidebar in a file manager. It's not as if I can have TileMap and TileMap.gd open side-by-side as tabs in the lower tab bar, or have "actual node content" and "tile set" as tabs in the selector for the lower pane.)

Likewise, switching node tabs normally won't alter what Script is being displayed while in Script mode... but if I click on the Script icon for a node, then it will start remembering that scene's tab should preserve that choice... but then if I pick a different file using the sidebar, it will stop remembering... and switching between node tabs may or may not switch the script you're looking at, depending on whether you click on a tab that is remembering which script was opened into it.

It's the worst of both worlds because it makes the tabs almost useless when the Script view is selected. I effectively see a vertical tab bar down the left for the scripts, and I wind up wishing I could just navigate up one level in the Scene pane and use it to navigate between scenes as well as within them.

At least I wouldn't constantly be second-guessing which UI widget I need to click to get to the view I want.

---

I also often find myself hitting Escape in the Help, as if that should back me out to the code I was working on before hitting F1... most likely because that's a common convention for exiting a dialog box like Open/Save and my intuition feels like F1-opened Help should behave that way.

---

Probably more trouble than its worth to change, but I have to pause every time I reach for Back because I have such a strong expectation that Back/Forward will be in the top-left of the HTML/richtext view.

If I had to TL;DR it down to a single sentence, navigation within the Godot UI is distressingly inconsistent.

[jeancallisti]

I've added items 9 and 10