-
-
Notifications
You must be signed in to change notification settings - Fork 22k
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
Fix scroll to symbol's documentation #100156
Conversation
Works on my end, thanks |
editor/editor_help.cpp
Outdated
@@ -215,7 +215,7 @@ void EditorHelp::_search(bool p_search_previous) { | |||
|
|||
void EditorHelp::_class_desc_finished() { | |||
if (scroll_to >= 0) { | |||
class_desc->scroll_to_paragraph(scroll_to); | |||
class_desc->connect("draw", callable_mp(class_desc, &RichTextLabel::scroll_to_paragraph).bind(scroll_to), CONNECT_ONE_SHOT | CONNECT_DEFERRED); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
class_desc->connect("draw", callable_mp(class_desc, &RichTextLabel::scroll_to_paragraph).bind(scroll_to), CONNECT_ONE_SHOT | CONNECT_DEFERRED); | |
class_desc->connect(SceneStringName(draw), callable_mp(class_desc, &RichTextLabel::scroll_to_paragraph).bind(scroll_to), CONNECT_ONE_SHOT | CONNECT_DEFERRED); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if a call_deferred()
is enough now, without connect to the draw
signal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thread can't directly update scrollbars, so it is done in the draw. This change is correct (scrolling after finished
and first redraw), but we might want to add another signal instead of directly connecting to the draw
(finished
probably should not be changed, since other code might expect it to fire even for hidden RTL that will never redraw).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ydeltastar WDYT about the above suggestion? Do you want to implement that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. I added a signal that triggers after loading, processing, and validation for drawing. It also needed an equivalent method for is_finished()
so the EditorHelp
could use the signal correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm very perplexed on the addition of another signal. It sounds "needlessly" confusing. I'd be wary as developers may use one or the other without understanding the difference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, all it does is simulate a one-shot connection to draw
. It is very specific, can only happen in the first draw after finished
so it could be just a note in the documentation as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe you can connect to finished
and then in the callback connect to draw
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's what I did in the first iteration. I reverted the PR to it and added a note to the finished
signal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, simpler solutions are better. No point in adding a signal if it does the same.
I think the problem is in the Why it happens sometimes for the My fix removed code that was calling the whole help logic twice, so it fixed a problem, but the scrolling is still not stable (enough). For now, I wonder if simply calling EDIT: What is weird is that the |
I use a 120hz one. I get it every time I use search in dev6 |
From what I debugged, #90035 didn't fix the issue because the offsets were already calculated in that code path. Having it or reverting it didn't have any effect. I think it is good to have it connected to This PR affects another code path when the documentation is loaded and processed for the first time. When
Yes, the main issue is that godot/scene/gui/rich_text_label.cpp Lines 1899 to 1902 in a372214
I think it makes sense since these calculations are dependent on theme changes and only relevant when drawing. So connecting to the |
Note that AFAIK, the RichTextLabel for the editor help updates on a thread, so there might be race conditions. CC @bruvzg |
@passivestar Does |
yeah it does |
bb481c0
to
f87ba44
Compare
f87ba44
to
6478806
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixes the bug.
Thanks! |
Same fix as #90035 but for a different code path.
A doc page goes through this code path the first time it opens but depending on the device it will execute too early so the correct offsets weren't calculated yet.