Move the signal connection UI from the Node dock to the inspector

[groud]

Describe the project you are working on

Godot

Describe the problem or limitation you are having in your project

I've always felt like switching to the Node dock to edit signals felt a bit weird. The signal connection UI is very similar in shape as the inspector, but they are separated for some reason.

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

Eventually, I'd like to get rid of the Node dock. It is, IMHO, a bit confusing, as the Inspector is already editing the selected Node. It also feels a bit inconsistent to me that signals and groups would get a special treatment with a dedicated dock, unlike any other node's property editor which are either in the inspector, or in the bottom panel.

Instead, I'd like to move the signals inside the inspector, within each category. And maybe have a special editor for groups too (that could come later on though).

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Basically, the current signal connection would be moved to the inspector, something like that:

Also, it's not on the mockup, but I think we should probably display the number of connections in the "signal" subcategory. It would make it easier at a quick glance to know whether or not you have a connected signal there.

Eventually, I believe we could also implement some filtering system or something like that (like, to only show signals/onlyshow properties/show both). But well, for the most part, it seems like collapsing stuff works well enough and does not bloat the inspector so much.

If this enhancement will not be used often, can it be worked around with a few lines of script?

It's core.

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

It's core.

[CarpenterBlue]

I would be ok with making the current long list part of the inspector but splitting it under each class like this seems bit excessive. It would certainly make it harder to find the signal you need. On the other hand, I basically never use the signal window as I prefer to connect the signals from code and often use this window only as quick reference so maybe I am not target audience for this change.

[groud]

It would certainly make it harder to find the signal you need.

Yeah, that's a fair point. I would probably solve it by having a button that would filter signals. When enabled, the inspector would almost be the same as the current Node dock (only "signals" subsections visible and extended).

[JustMog]

to me this is just interleaving two unrelated things and making both harder to find as a result. i don't see the benefit.

[TheDuriel]

At this point the inspector is already significantly too busy. I'd love to be able to move more things into more separate docks, not the opposite.

[ettiSurreal]

This would probably not be ideal when using the setting that removes dropdown menus (I forgot how it's called and I don't feel like looking for it).

[dogman035]

Spent a bit thinking about it, and I think I'm against this one. At least in this implementation.

I've been teaching a friend who's relatively new to gamedev. Clutter in the inspector is one of the major pain points they've had, it gets confusing finding where everything is at a glance. There's a learning curve where you have to dig through a lot of dropdowns, before you memorize where everything is.

I feel like this adds more that clutter, and makes that learning curve more difficult. Whereas the current setup only requires the user to notice the signals tab.

I also think having a separate signals dropdown for each inherited class will only make things harder to find for new users. It's very easy to miss the fact that options are even separated by class, for a new user, so they might not even notice that there's multiple signal tabs in the first place.

The current signals tab shows a list of all possible signals on that node, with a separator showing which class they're related to. It's very clear and readable, and I'd argue it even helps explain how inheritance works in Godot as well.

And I do think new users are the major focus here. For more experienced people, they're likely not using editor signals at all. Since it's faster and more readable to connect things in-script.

If the goal is to remove the nodes tab, I think signals would need to sit in their own section of the inspector. Possible below the script load section.

It'd make sense, given that signals aren't necessarily related to the node's script or properties anyways. Whereas the rest of the inspector is.

[JoNax97]

I think it's weird for the node tab to be a separate thing, specially since resources also have signals (which afaik can't be accessed via the editor, only via script).

I'd rather have the inspector have internal tabs (properties, signals, groups). Of course the groups tab would be hidden if inspecting a resource.

There's a proposal for adding favorites to the inspector. If combined with this, you can have a favorites tab that would allow mixing and matching properties and signals in any order for advanced users.

[groud]

I'd rather have the inspector have internal tabs (properties, signals, groups). Of course the groups tab would be hidden if inspecting a resource.

Yeah, I think that could work too, a blender-like tab system could help.

But the layout might be a bit tricky, as if we go with vertical tabs, we kind of have some wasted space if the whole tab-bar isn't full. Blender has a ton of tabs, and I can't think of that many tabs for Godot:

We might have to find creative ideas to no waste this space.

[kidManuel]

I'm not against removing the Node tab/rethinking the Node inspect area. Probably not with the exact implementation described in the OP, but something.

I taught (and currently teach) Godot to people of different ages and grades of programming knowledge and I've gotten the "My node thingy doesn't look like yours!"+"you are looking at the wrong tab" quite a few times (I would go as far as to say at least once per student and sometimes more). Even sometimes "oh, you are in the correct tab, but you are actually in the Groups sub-tab". Even I usually say to these people to just hook to the signals via code, so they don't have to switch back and forth between tabs to see what's connected (which is what I do)

So yeah, bottom line, I don't personally particularly like the Nodes tab, and have found it a confusion/complexity point among newer programmers, but I agree that just dumping every signal in the Node Inspector is probably not the right way to go.

As an additional bit, Looking at it I realize I have no idea what the History tab is. I have never used, never seen it mentioned in any tutorial, googling "godot node inspector history tab" and similar searches gives no relevant results in the first page.

[noidexe]

With the current workflow I switch to the signals tab and I can quickly see all the signals the node has, in order of inheritance, if and what they have connected and quickly add/remove/edit connections. The signal dock remains visible until I switch back to the inspector, that means connecting many different nodes is easy. I can even have the inspector dock and the signals dock side by side with both visible all the time, if that's relevant to my workflow.

In the example you are giving we have something as basic as a Node2D and I already have to hunt for each signal section and uncollapse it. In the best case scenario where all the signals fit in one screen, I still have to look up and down and move the mouse up and down to look for and select what I want. If it doesn't fit, then I need to scroll up and down and I cannot even have everything visible at the same time. Now if you are working on UI and need to connect several nodes you need repeat all that every time you switch to a different node.

I've always felt like switching to the Node dock to edit signals felt a bit weird. The signal connection UI is very similar in shape as the inspector, but they are separated for some reason.

I think in that case before making any changes it'd be important to find out why it was implemented that way. To me, the reason seems to be usability. Connecting signals is a different activity from changing properties.

What are the guiding principles behind your proposal? How will the change improve the user experience? What I see is a change that cares about consistency, taxonomies, and logic (from the point of view of how the features are implemented) but at the expense of usability.

If anything, and based on my experience at the classroom I can tell you that Signals and Groups being inside a tab called "Node" was confusing to my students. I think you could make signals it's own dock, while it makes more sense for groups to be part of the inspector. But I feel scattering signals across the whole inspector will do anything but reduce confusion

[kitbdev]

• related https://github.com/godotengine/godot-proposals/discussions/9052

[mournguard]

That seems like an unnecessary change where any pros we could dig out would have equal or worse cons. If the concern is having a clearer link with the source node I think one thing that could be done would be to reuse the headers from the other tab so it stays consistent. As for the "Node" tab being weird, using the 2nd row of tabs could work well.

[groud]

What are the guiding principles behind your proposal? How will the change improve the user experience? What I see is a change that cares about consistency, taxonomies, and logic (from the point of view of how the features are implemented) but at the expense of usability.

Oh yes. Indeed it is a way to make things more consistent and easier to find. But indeed there are downsides as a lot mentioned.

Personally, I don't feel like connecting a signal is a lot different from editing a property (for me it's just about editing a node and its behavior), but I understand it might not be everyone's case.

In any case, it's just about how easy the property/signal you are looking for is easy to find. I guess the class you get the property/signal from is probably more important for properties than for signals where you would want to see everything at once.

[groud]

That seems like an unnecessary change where any pros we could dig out would have equal or worse cons. If the concern is having a clearer link with the source node I think one thing that could be done would be to reuse the headers from the other tab so it stays consistent. As for the "Node" tab being weird, using the 2nd row of tabs could work well.

Hmm, that looks like a nice mockup, That could work too to make the Node and Groups tabs look more related to the edited node.

[ARGH0]

I would rather like to have seperate tabs/docks that are named Signals and Groups. It would then grab the context the same as the node tab. This way I can choose where I want them with the docking system.

[groud]

I would rather like to have seperate tabs/docks that are named Signals and Groups. It would then grab the context the same as the node tab. This way I can choose where I want them with the docking system.

The whole point of the proposal is kind of having everything in the same place, not scattered around. And, like, I am not sure why you would need to edit both signals and properties at once, so they don't really need to be separated IMO.

[wwwriks]

I think it looks clean Im all for it. feels encapsulated ya know

[TokisanGames]

Definitely don't want signals in the inspector, as it's already cluttered in there. I mandate to my team that we do not connect signals in the UI. We connect all signals via code for searchability and git among other reasons. Signals are already listed in the searchable help, or the node tab, so they aren't hidden.

I understand signals might be thought of as a property, but the reality is you don't see any of the current connections, except the ones saved in this particular scene. That is, there are lots of signals connected from all over in other classes that do not show up in the UI, making it of marginal use at best, and hiding information or deceptive at worst.

A better proposal would be a separate signals tab that shows all the available ones and allows them to be connected, but it also works like the debugger showing all object instances that are connected to the signals, from all classes, anywhere. Maybe even remove the ability to connect in the UI, as it's really a terrible choice one you get out of the beginner development phase, or start working with a team, and instead this signal tab becomes a debugging monitor.

[ARGH0]

I would rather like to have seperate tabs/docks that are named Signals and Groups. It would then grab the context the same as the node tab. This way I can choose where I want them with the docking system.

The whole point of the proposal is kind of having everything in the same place, not scattered around. And, like, I am not sure why you would need to edit both signals and properties at once, so they don't really need to be separated IMO.

Yes, I do agree on the scattering. To explain my point of reference, I have it docked in Godot like this:

The reason I like this setup is that I am able to look at the available signals and properties at the same time while having the code editor open. This reduces the needed of clicks needed for me to view information on the nodes.

But i have to admit that after thinking about it more thoroughly, there are not that many scenarios in which I am needing it both at the same time.

Seeing the mockup of @mournguard, I think that would be a great implementation. It reminds me of the way Visual Studio handles Events on WinForm pages within the properties pane. (link for reference)

[elenakrittik]

Personally, i agree the problem is real and having to switch tabs (or re-arrange them) to do stuff with signals is not ideal. But this implementation does not solve this issue in any way for me, because as many others have pointed out already, the Inspector tab is already under a heavy load. mornguard's mockup looks way better, although it's still not a 100% solution.

[Norrox]

At this point the inspector is already significantly too busy. I'd love to be able to move more things into more separate docks, not the opposite.

I would like this to, and I would like to have more than two docks beside each other

[Nodragem]

I am using Signals with Resources at the moment.

The one good thing I can think of about having Signals in the inspector is that we could connect Resources' Signals inside the Editor UI. At the moment there is no way (?) to use the UI to connect resources' signals to nodes; we need to burry these connections in code.

However, I also believe that the inspector is too busy, and I think it is better that Signals are in their own panel. Just thought it was interesting to highlight the case of Signals for Resources.

[AThousandShips]

Signals from resources being editable in the inspector makes no sense, they're shared, not specific to one scene, unlike nodes, so that's not stable

[groud]

Signals from resources being editable in the inspector makes no sense, they're shared, not specific to one scene, unlike nodes, so that's not stable

Some resources are scene specific (if made unique) and the fact they are shared isn't necessarily a problem I believe. But that's off-topic anyway.

[dugramen]

I really liked @mournguard's mockup, so I decided to make a plugin out of it. Turns out the editor is really capable of 'hacked' layouts thanks to the node system.

https://github.com/dugramen/godot-merge-node-docks

[derket25]

You can move the resource editing buttons to the menu, I don't think anyone uses them very often. Move the History buttons to the Scene tab, they relate to nodes, not the inspector. On both tabs, add a button to the menu to switch the visibility of the filter panel.