Add sticky tree item support

[dugramen]

addresses godotengine/godot-proposals#13998 for Trees

Video demo:

2026-01-31.20-06-23.mp4

[llama-nl]

tested it on Android, I am having a problem when use multiple nested node:

az_recorder_20260201_082540_edited.mp4

[dugramen]

Ah right. It currently sticks at an unlimited depth. Maybe I can just hard cap it to the last few elements. Or maybe up to like half of the full height

Edit: looks like it's not horizontally scrolling either. I'll have to fix that

[AdriaandeJongh]

if you cap the depth and that depth is reached, will from that point on the sticky headers also scroll again as if normal? because if they remain sticky, that might be very confusing…

[dugramen]

I think they could show another scroll hint shadow at the top, to indicate there's more sticky elements. Or maybe have like a ... item at the top?

Edit: nvm I realize the issue with capping to the last elements. It would make items jump to the top. It's probably better to cap to the first few elements instead

[dugramen]

Ok I changed the setting to enable sticky items to an int, providing the maximum number of sticky elements. Horizontal scrolling should also work now.

2026-02-01.10-20-54.mp4

[Naros]

Suggested change

	ClassDB::bind_method(D_METHOD("set_max_sticky_items", "enable"), &Tree::set_max_sticky_items);
	ClassDB::bind_method(D_METHOD("set_max_sticky_items", "count"), &Tree::set_max_sticky_items);

[Naros]

If setting this to 0 is to imply the feature is disabled, there should be a note and/or sentence here that indicates calling the method with 0 disables the feature, and the Tree works as it did prior to this feature being added, particularly for EditorPlugin authors who may not want this to be enabled.

[Meorge]

I agree that it could be nice to specify that explicitly. However, unless I'm misunderstanding, I think that would be the implied result of this being 0 anyways? As in, zero tree items would be allowed to stick to the top while children are in view?

[dugramen]

pushed the changes and explicitly mentioned that a max of 0 disables sticking, just in case

[Naros]

I'll defer to AThousandShips on the language, but LGTM.

[Kazox61]

Tested the latest version and it works as expected.

[AdriaandeJongh]

Played around with this and think this is a great feature in general. A few notes:

• I was unable to raise the sticky count above 6. Why not? IMO it should be able to go to a large number just because it will enable this UX improvement on various specific workflows. Even in Rift Riff's settings screen I easily hit 6 layers of organization deep and it wasn't enough. I suggest having a maximum of 16.

• Looking at the trees in my commercial-game-grade projects, I think the default maximum sticky items of 3 is too low making the sticky headers less useful than they can be. The point of that number is to avoid infinite sticky items and filling the entire panel with stickies making the panel unusable.
  -- It's not trivial to land on a better number without making assumptions about some sort of median height of Godot user's scene panel.
  -- ... but making assumptions based on my experience with the editor, 5 would be a better default.

• I'm not sure yet whether this should be improved and how it even could be improved, but at the core of the sticky header is that it 'hides' all the in-between nodes that are not the shortest path to root. However, there is currently no visual indication of when there are nodes in between the sticky ones or not. For example, in the video below, there is no visual indication that Control1 exists when Control2 sticks to the top:

Screen.Recording.2026-02-27.at.10.57.21.mp4

But like I said, I'm not sure we can and should address this. My first thought would be to add a tiny indicator like this one and stick it in between all the edges that hide nodes... but it'll very soon can crammed with all those icons, so I don't even like that solution much.

• And finally, here's a few screenshots of a bunch of trees in Rift Riff showing how much more readable the tree becomes after this change – as well as notice that a few more stickied items above 6 would have been convenient for us:

[dugramen]

I pushed the suggestions. As for indicating when it reached its sticking limit, I feel like the difference in indentation between the normal and stuck content kind of does that already. Though there might be some cases / configurations that make it less clear, not sure

[AdriaandeJongh]

hey yeah sorry i was unclear! see the image below, an annotated screencap of my video above: i was talking about the nodes hidden at the red arrow, while you’re talking about the itens hidden by the orange arrow. i agree that the items hidden by the orange item are fine as the indentation plus the drop shadow are a clear giveaway. however, nothing indicates there are nodes in between Control and Control2, where the red arrow is.

again, i’m still not sure if we could even fix or address this.

[dugramen]

Ah that makes sense. Maybe it could add shadows there too. It might look weird if there's a lot of shadows, but I can try it

[AdriaandeJongh]

adding another shadow will make it unclear where the scroll container starts, so that’s probably not gonna work… hmm yeah idk.

[AdriaandeJongh]

I tried a few things like putting lines and icons in between but their either have to be extremely small making it unreadable, or it's still kind of unclear why there is a line in there all of a sudden. The best I could come up with was this simple line giving at least some indication of there being something in between.... but I'm not sure it's all that clarifying. What do you think?

[dugramen]

Oh ok thanks. I updated visual studio recently, maybe that messed some stuff up

[AThousandShips]

Turns out this was actually the account you made all your previous contributions with, and it's "invalid", i.e. it's not actually linked to your GitHub profile, so you're still a first time contributor, this being merged would make you count as a contributor (no contributions to this repo has been counted because you didn't use a proper account to sign the commit)

Resolved

[dugramen]

Lol a lot of weirdness going on today. Thanks for letting me know, and sorry for the trouble

[dugramen]

It seems #118733 added a new canvas item stylebox_ci, introducing buggy visuals in this PR. I'll have to fix it in the morning

[dugramen]

Ok bugs should be fixed now

[KoBeWi]

Some glitched overlap

godot.windows.editor.dev.x86_64_FDmVCY5xAM.mp4

[KoBeWi]

Other than the above (which is a minor thing tbh) looks fine.

[dugramen]

That should fix it

[Repiteo]

Thanks! Congratulations on your first merged contribution! 🎉

[passivestar]

Congratulations on your first merged contribution!

dugramen has 22 merged PRs 😂

[AdriaandeJongh]

this pr comes in as the first best pr though!!! 😂

[passivestar]

idk the condensed inspector was kinda fire too but it's close haha

[dugramen]

😅 Thanks guys. Yeah my GitHub and local git emails got unsynced at some point, so GitHub thinks it's a different author

[TokageItLab]

This PR seems to be corrupting Skeleton3DEditor joint tree (issue #120991). We may also need to check for regressions in other places within the Editor where TreeItem is used.

We cannot know what is happening because there are no shadows. Also, I am not sure when the sticky behavior occurs.

The sticky behavior occurs when there are multiple siblings, but I believe it should not occur for siblings that have children while in the unfolded state.

For example, the following case is still understandable:

• a
  • b
    • c
    • d
    • e
  • f
    • g

↓ sticky

• a
  • b
    • e
  • f
    • g

However, I assume it should never occur in cases like the following (I think the #115697 (comment) probably has a similar perspective to mine):

• a
  • b
    • c
      • d
    • e
      • f
    • g
      • h
  • i

[AdriaandeJongh]

However, I assume it should never occur in cases like the following (I think the #115697 (comment) probably has a similar perspective to mine):

• a

  • b

    • c

      • d

    • e

      • f

    • g

      • h

  • i

to clarify: assuming ‘i’ has a lot of children that you are currently viewing, then it is expected that everything between a and i would be skipped. or in other words, a and i stick, hiding the rest of the tree that did not make up part of the hierarchy that lead to the nodes you are viewing.

with no other children, the same scenario can also expected to look as follows if the widow height would force it: (c-f skipped)

• a
  • b
    • g
      • h
  • i

[TokageItLab]

Even if they are skipped, it seems strange for the sticky behavior to occur while bypassing the parent. The lack of shadows is the biggest factor exacerbating the issue, but in cases like the one below, it is difficult to immediately find the parent of LeftHandIndex2.

For example, VSCode displays hidden parent-child relationships by concatenating them with slashes, as shown below:

fold.mp4

Since the currently merged sticky behavior lack such concatenation and end up looking like below, it causes a regression in terms of the visibility of the parent-child relationship.