Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changing visibility for a node in an editor dock has no effect #89211

Open
mr11stein opened this issue Mar 6, 2024 · 6 comments
Open

Changing visibility for a node in an editor dock has no effect #89211

mr11stein opened this issue Mar 6, 2024 · 6 comments

Comments

@mr11stein
Copy link

Tested versions

  • Reproducible in v4.3.dev4.official [df78c06]
  • Not reproducible in v4.2

System information

Godot v4.3.dev4 - Windows 10.0.19045 - Vulkan (Mobile)

Issue description

In plugins, if you toggle the visibility of a dock-attached node from false to true, the node stays invisible. Please see the attached project. The label in the dock on the bottom right corner should become visible when the Polygon2D node is selected in the scene tree. This works in 4.2, but not in the latest preview build.

Steps to reproduce

From an editor plugin, add a node in one of the editor dock slots. Toggle visibility to false and back to true. The node will not be visible, even if the "visible" is set to true.

Minimal reproduction project (MRP)

VisibilityBug.zip

@KoBeWi
Copy link
Member

KoBeWi commented Mar 6, 2024

It doesn't make sense .-.

	if is_instance_valid(side_panel_instance):
		side_panel_instance.visible = visible
		print(visible)
		prints(side_panel_instance.visible, side_panel_instance.is_visible_in_tree(), side_panel_instance.get_child(0).visible, side_panel_instance.get_child(0).is_visible_in_tree())

This prints:

true
true true true false
false
true true true false

Which means:

  • side_panel_instance is visible and visible in tree
  • its child is visible, but it's not visible in tree
  • when you set visible of side_panel_instance to false, nothing of the above changes

That said, the side_panel_instance is inside TabContainer, which manages children visibility. It might explain why making the content invisible has no effect (and you really shouldn't be doing it with docks), but does not explain why the child would be invisible.

@AlessandroCampagna

This comment was marked as spam.

@mr11stein
Copy link
Author

That said, the side_panel_instance is inside TabContainer, which manages children visibility. It might explain why making the content invisible has no effect (and you really shouldn't be doing it with docks), but does not explain why the child would be invisible.

What should I do instead? Add/remove the side_panel_container?
Still, it was working in 4.2, so there might be a regression, no?

@KoBeWi
Copy link
Member

KoBeWi commented Mar 7, 2024

Still, it was working in 4.2, so there might be a regression, no?

Yeah this is a bug from TabContainer changes. It does have logic to handle this case, but something works incorrectly here.

Hi I'm new here and would like to work on this.

That's not really a suitable issue for newcomers.

@AlessandroCampagna

This comment was marked as off-topic.

@kitbdev
Copy link
Contributor

kitbdev commented Mar 7, 2024

It's probably in TabContainer::_on_tab_visibility_changed(), from #87194. Maybe because it is a visibility callback?

What should I do instead? Add/remove the side_panel_container?

Adding and removing it should work. Or if you want the panel to stay open, you could change the visibility of a child of the panel instead.
Something like this in _make_visible:

if visible and not side_panel_instance.get_parent():
	add_control_to_dock(EditorPlugin.DOCK_SLOT_RIGHT_BL, side_panel_instance)
elif side_panel_instance.get_parent():
	remove_control_from_docks(side_panel_instance)

Edit: This would probably be a good use case for exposing open_dock() and close_dock() when that gets implemented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants