Editor: Display deprecated/experimental messages in tooltips #89058

dalexeev · 2024-03-01T18:51:19Z

Resolves Cannot interact with popups inside the editor #90137 (for EditorHelpBit).

akien-mga · 2024-04-12T08:57:08Z

I see there's significant refactoring work beyond just adding deprecated/experimental messages. Could you write a few words to outline the rationale for the changes and help with the code review?

dalexeev · 2024-04-12T09:10:30Z

Some refactoring was necessary to avoid code duplication for different types of class members, so the HelpData structure was added. Also, I needed to unify the custom descriptions, since EditorHelpBit is used in several places in the editor.

Additionally, I implemented hover and scroll functionality since sometimes the descriptions are too tall to fit on the screen.

Outdated

1.mp4

KoBeWi · 2024-04-15T14:34:44Z

The experimental/deprecated message looks like part of the description. It needs to be more separated IMO.

dalexeev · 2024-04-15T14:59:31Z

This matches the current appearance in the main help. Deprecated/experimental messages are simply inserted as paragraphs before the description. The only indicator is an icon and red/yellow bold text. In the future we may add some decorative elements if we deem it necessary. But in my opinion, it’s already quite noticeable.

editor/connections_dialog.cpp

KoBeWi · 2024-04-15T16:25:02Z

editor/connections_dialog.cpp

+	}
+
+	EditorHelpBit *help_bit = memnew(EditorHelpBit(p_text));
+	EditorHoverableTooltip *tooltip = memnew(EditorHoverableTooltip(const_cast<ConnectionsDockTree *>(this)));


You can avoid const_casts if you store the Control in a variable and then connect the signals in _notification().

I don't think this is possible. In any case you will need to remove the qualifier, since you cannot assign const T * to T *.

Then maybe move the const cast to ~~EditorHoverableTooltip()~~ show_tooltip() and make the argument const? It would at least make creating tooltips cleaner.

I'd rather keep the const_cast in calls rather than move it into the definition. Because EditorHelpBitTooltip requires a non-const pointer for connect(). In my opinion, it is better not to hide the problem.

editor/plugins/theme_editor_plugin.cpp

editor/editor_inspector.cpp

KoBeWi · 2024-04-15T21:40:34Z

editor/editor_help.h

+// Standard tooltips do not allow you to hover over them.
+// This class is intended as a temporary workaround.


I'd say it's a proper solution, not a workaround. If you want to do more than a standard tooltip, make a more specialized one.
Though it sucks that it basically bypasses the tooltip system (returning empty Controls as custom tooltips is an interesting solution, but you solved a problem that I myself faced with tooltips).

I think a better solution would be to allow hovering over tooltips (we can make this configurable). In this case, when you hover over a tooltip control, another tooltip may appear. That is, we need a tooltip stack.

editor/editor_help.h

KoBeWi · 2024-04-15T22:14:40Z

editor/editor_help.cpp

+	title = memnew(RichTextLabel);
+	title->set_fit_content(true);
+	title->set_selection_enabled(true);
+	//title->set_context_menu_enabled(true);


Commented-out code should be removed.

Added TODO comment.

Why would you want the context menu though?

See Enable RichTextLabel context menu if selection is enabled #74114.

Some people like me are used to copy text with context menu in certain scenarios. I have no idea why I'm not using Ctrl + C here.

editor/editor_help.cpp

dalexeev · 2024-04-16T08:42:34Z

Seems like this PR also fixes #90395

No, this PR doesn't fix the bug. See #90446 instead.

The tooltip appears out of screen.

I'm not sure how to fix this.

Main window loses focus when tooltip appears.
EDIT: This one might be unsolvable though 🤔The tooltip does not block events or anything, so it's not that bad.

This is probably platform specific. On Linux (KDE), the parent window only loses focus if I click on the tooltip.

I'm not sure about the horizontal separator. It's somewhat ugly IMO, especially in small tooltips.

Also I already said the horizontal separator is meh, but after checking other instances of help bits, it looks even worse outside the tooltips. Like here, the content is very wide, which makes the separator super long and you are wasting a line of space.

I fixed this by changing the title background and making the minimum content height about 2 lines:

The help panel in property selector jumps a lot

Made the height of embedded EditorHelpBits fixed.

KoBeWi · 2024-04-16T09:05:59Z

I looked into the popup out of screen issue and this happens when you use call_deferred():

It's arguably better, because you can read it at least 🙃
idk how to make it right, I might try some other solutions.

EDIT:
Update to the window focus problem. Pressing Alt+PrintScreen to make a screenshot of the current window will make a screenshot of the popup. This does not happen with regular tooltips. I didn't check exactly, but you likely did something with popup flags to allow clicking it and it has unwanted side-effects. Still, since it doesn't break input, it doesn't need to be fixed right now.

dalexeev · 2024-04-17T09:52:21Z

The tooltip appears out of screen.

Main window loses focus when tooltip appears.

It looks like I managed to solve both problems.

editor/editor_help.cpp

KoBeWi · 2024-04-17T12:57:27Z

I actually found another bug .-.
When doc tooltip appears, you can't use keyboard. It's annoying when you e.g. try to set position, but unfortunate mouse placement opens a tooltip and you can't write in spin slider.

dalexeev · 2024-04-17T13:33:43Z

When doc tooltip appears, you can't use keyboard.

I tried different flag combinations, but I could not get the keyboard input to be passed to the parent window, and the mouse input to be processed in the popup. If I fix the keyboard issue, then hyperlinks in the popup become unclickable and vice versa.

KoBeWi · 2024-04-17T13:42:02Z

Unless you manage to fix it, it's better to have links unclickable than to introduce regression. Scrolling alone is a great improvement already, the link issue could be fixed later.

dalexeev · 2024-04-17T13:56:09Z

it's better to have links unclickable than to introduce regression

I'm not sure if this is a regression. It's somewhat expected that while an interactive popup is on the screen, it will prevent input. Previously, the tooltip was non-interactive, you simply couldn't hover over it.

Scrolling alone is a great improvement already, the link issue could be fixed later.

The problem is that the hyperlinks look interactive, an underline appears on hover, but nothing happens on click. To me this looks like a bigger bug than the problem above.

Unless you manage to fix it

We could try forwarding keyboard input (except ui_cancel) to the parent viewport.

KoBeWi · 2024-04-17T14:02:35Z

I'm not sure if this is a regression. It's somewhat expected that while an interactive popup is on the screen, it will prevent input.

But it's not expected that when you have an input field active and focused, you are not able to input text. I discovered this issue by accident, because I was doing something using a build with this PR included; it's confusing and makes editing values troublesome, because you have to be aware of your cursor and avoid hovering the inspector.

We could try forwarding keyboard input (except ui_cancel) to the parent viewport.

That could work. I think _window_input method can be used.

kitbdev · 2024-04-17T15:02:00Z

Sounds related to Tooltips break hover events for underlying controls #73926

Edit: maybe its not the cause, that does break keyboard inputs for popups, but not for the Inspector.

dalexeev · 2024-04-18T08:51:37Z

Scrolling alone is a great improvement already, the link issue could be fixed later.

The problem is that the hyperlinks look interactive, an underline appears on hover, but nothing happens on click.

@KoBeWi If you agree with this, let's do it this way. This PR is already too big and to be honest I don't want to mess around with input forwarding, at least right now.

KoBeWi · 2024-04-18T09:02:10Z

If you agree with this, let's do it this way.

What way? Like it is now? Or with disabled clicks?

dalexeev · 2024-04-18T09:09:45Z

Options:

(Current) Keyboard input in the parent window does not work as long as the popup is displayed.
Hyperlinks in the popup are not clickable (but look interactive visually) and the popup cannot be hidden by pressing Escape. Scrolling in the popup works.

KoBeWi · 2024-04-18T09:15:13Z

I'd go with 2. The links were already unclickable before. Now it would be a bit more confusing (since you can hover them), but it's a bug with the new feature, while the other option is a regression. It's better to add new things and iron them out than to break old things.

dalexeev · 2024-04-18T10:46:48Z

When doc tooltip appears, you can't use keyboard. It's annoying when you e.g. try to set position, but unfortunate mouse placement opens a tooltip and you can't write in spin slider.

Fixed by forwarding input to the parent viewport.

dalexeev · 2024-04-18T11:33:39Z

Added request_hide signal handling to EditorBuildProfileManager and EditorFeatureProfileManager to be consistent with CreateDialog and PropertySelector.

akien-mga · 2024-04-19T14:32:13Z

Thanks!

dalexeev added enhancement topic:editor labels Mar 1, 2024

dalexeev added this to the 4.3 milestone Mar 1, 2024

Mickeon self-requested a review March 1, 2024 23:09

dalexeev force-pushed the editor-help-bit-deprecated-experimental branch from 0a8c424 to 3aa5161 Compare April 12, 2024 08:47

dalexeev marked this pull request as ready for review April 12, 2024 08:52

dalexeev requested review from a team as code owners April 12, 2024 08:52

dalexeev force-pushed the editor-help-bit-deprecated-experimental branch from 3aa5161 to 6afd006 Compare April 12, 2024 14:18

This comment was marked as resolved.

Sign in to view