-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
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
Custom tooltip placement bug when using _make_custom_tooltip #39677
Comments
This turns out to be a very simple one. The tooltip code in Using |
Actually, the documentation on
So it was a deliberate decision to use min_size instead of the real size. In that case I'd say this is not a bug, it's an expected behaviour. I'd still argue using a size instead of min_size would be better solution but that's not the decision for me to make. |
What's puzzling is that even forcing a non-zero func _make_custom_tooltip(for_text):
var tooltip = $Tooltip.duplicate()
var rtl = tooltip.get_node("MarginContainer/RichTextLabel")
rtl.bbcode_text = for_text
# Work around https://github.com/godotengine/godot/issues/18260.
# FIXME: Not working :(
rtl.rect_min_size = rtl.rect_size
return tooltip Still produces the same result. The |
The problem with
This is all pretty messy, I think all |
This patch makes setting a custom diff --git a/scene/main/viewport.cpp b/scene/main/viewport.cpp
index 1063309130..7db7b28916 100644
--- a/scene/main/viewport.cpp
+++ b/scene/main/viewport.cpp
@@ -1607,6 +1607,8 @@ void Viewport::_gui_show_tooltip() {
}
rp->add_child(gui.tooltip_popup);
+ gui.tooltip_popup->show();
+
gui.tooltip_popup->force_parent_owned();
gui.tooltip_popup->set_as_toplevel(true);
if (gui.tooltip) // Avoids crash when rapidly switching controls.
@@ -1629,7 +1631,6 @@ void Viewport::_gui_show_tooltip() {
gui.tooltip_popup->set_size(r.size);
gui.tooltip_popup->raise();
- gui.tooltip_popup->show();
}
void Viewport::_gui_call_input(Control *p_control, const Ref<InputEvent> &p_input) { I don't know if this could introduce flickering to have the |
And as I supposed, this also works: diff --git a/scene/gui/panel_container.cpp b/scene/gui/panel_container.cpp
index 74663c33e3..7e7daa780d 100644
--- a/scene/gui/panel_container.cpp
+++ b/scene/gui/panel_container.cpp
@@ -43,7 +43,7 @@ Size2 PanelContainer::get_minimum_size() const {
for (int i = 0; i < get_child_count(); i++) {
Control *c = Object::cast_to<Control>(get_child(i));
- if (!c || !c->is_visible_in_tree())
+ if (!c || !c->is_visible())
continue;
if (c->is_set_as_toplevel())
continue; (exclusive of the other patch) @reduz changed |
Oh, you are on the right track here! It is indeed the problem with how func _make_custom_tooltip(for_text):
# Uncomment this to fix bug.
#return null
var tooltip = $Tooltip.duplicate()
tooltip.visible = true
var rtl = tooltip.get_node("MarginContainer/RichTextLabel")
rtl.bbcode_text = for_text
rtl.rect_min_size = rtl.rect_size
return tooltip The only issue still is that the RTL |
# Uncomment this to fix bug.
return null This would return a default tooltip, not my custom one :) |
Whoops, sorry, my bad. Forgot to remove that from the MRP code :) |
Here's cleaned up code. func _make_custom_tooltip(for_text):
var tooltip = $Tooltip.duplicate()
tooltip.visible = true
var rtl = tooltip.get_node("MarginContainer/RichTextLabel")
rtl.bbcode_text = for_text
rtl.rect_min_size = rtl.rect_size
return tooltip The important change is setting tooltip visible after duplicating it so the parent |
This requires working around two engine bugs: - RichTextLabel doesn't properly set its minimum size: godotengine/godot#18260 - Custom tooltip placement fails if the custom tooltip is not visible beforehand: godotengine/godot#39677 (This should be fixed in 3.2.4, but the workaround doesn't hurt.)
So I was about to make a patch with #39677 (comment), but thinking more about it, maybe this should be a requirement on the user side to make their custom tooltip visible before returning it in For So in the end, maybe this just needs a note in the documentation of |
The return type is Control, and users should make sure to return a visible node for proper size calculations. Moreover in the current master branch, a PopupPanel will be added as parent to the provided tooltip to make it a sub-window. Fixes godotengine#39677.
Yes, I think it is reasonable to ask of user to return a visible control. Also, it might be just my personal preference, but I tend to save the scene tree branches that I plan on instantiating as scenes, rather than storing them hidden in the containing scene. That way they are stored in the exact state I want them to appear when instantiated. If users prefer this workflow too, they wouldn't even come across this problem with returning invisible control. |
Actually, I would go as far as to say that the If I, as a user, find that my custom tooltip is not rendering, I'd find it easier to figure out that I made a mistake and returned an invisible control. If, instead, I get a tooltip but with a wrong position, I would assume I did everything right and there is a bug in the engine - after all, this was your case too. It would be a whole different story if the |
But in the end, this is not really a problem with the popup API, it is more deep-rooted problem with controls and |
This requires working around two engine issues: - RichTextLabel doesn't properly set its minimum size: godotengine/godot#18260 - Custom tooltip placement fails if the custom tooltip is not visible beforehand. It's not a bug per se, but documentation will need to be made clearer about this requirement: godotengine/godot#39677
The return type for `_make_custom_tooltip` is clarified as Control, and users should make sure to return a visible node for proper size calculations. Moreover in the current master branch, a PopupPanel will be added as parent to the provided tooltip to make it a sub-window. Clarifies documentation for `Control._make_custom_tooltip`, and shows how to use the (until now undocumented) "TooltipPanel" and "TooltipLabel" theme types to style tooltips. Fixes godotengine#39677.
The return type for `_make_custom_tooltip` is clarified as Control, and users should make sure to return a visible node for proper size calculations. Moreover in the current master branch, a PopupPanel will be added as parent to the provided tooltip to make it a sub-window. Clarifies documentation for `Control._make_custom_tooltip`, and shows how to use the (until now undocumented) "TooltipPanel" and "TooltipLabel" theme types to style tooltips. Fixes godotengine#39677. (cherry picked from commit c5d8daf)
The return type for `_make_custom_tooltip` is clarified as Control, and users should make sure to return a visible node for proper size calculations. Moreover in the current master branch, a PopupPanel will be added as parent to the provided tooltip to make it a sub-window. Clarifies documentation for `Control._make_custom_tooltip`, and shows how to use the (until now undocumented) "TooltipPanel" and "TooltipLabel" theme types to style tooltips. Fixes godotengine#39677.
The return type for `_make_custom_tooltip` is clarified as Control, and users should make sure to return a visible node for proper size calculations. Moreover in the current master branch, a PopupPanel will be added as parent to the provided tooltip to make it a sub-window. Clarifies documentation for `Control._make_custom_tooltip`, and shows how to use the (until now undocumented) "TooltipPanel" and "TooltipLabel" theme types to style tooltips. Fixes godotengine#39677. (cherry picked from commit c5d8daf)
Godot version:
3.2 (b3af0b2)
Note: Commit b3af0b2 is needed for RichTextLabel's 'Fit Content Height' property used in the MRP - but the bug is reproducible even without it / without using RichTextLabel.
This is "reproducible" in the
master
branch but harder to see as a bug since default tooltip also go out of the window just fine now with multiple window support.OS/device including version:
Linux
Issue description:
When showing tooltips,
Viewport
is responsible for ensuring that the tooltip panel will be within the bounds of the viewport, to avoid having content cut on the edges:Control
has a virtual method_make_custom_tooltip
that can be overridden from scripts to return a custom Control that will be used as the tooltip (still nested in aTooltipPanel
inViewport
). When using this, the logic that makes it stay within bounds seems to fail:I don't know why yet, so opening an issue.
Relevant code in
3.2
branch (might be relevant inmaster
too):godot/scene/main/viewport.cpp
Lines 1592 to 1632 in 42a3150
Steps to reproduce:
_make_custom_tooltip
returns a custom Control (here aPanelContainer
) or the default tooltip. Uncomment#return null
inaddons/debug_watermark/debug_watermark_label.gd
to use the default tooltip.Minimal reproduction project:
godot-debug-watermark.zip
Example code from https://github.com/akien-mga/godot-debug-watermark/tree/custom-tooltip
The text was updated successfully, but these errors were encountered: