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.

Sign up for GitHub

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

Jump to bottom

Find/replace overlay: reassign to changed shell asynchronously #1945 #2096

Merged
merged 1 commit into from
Jul 18, 2024
Merged

Find/replace overlay: reassign to changed shell asynchronously #1945 #2096

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 7 additions & 5 deletions ...nch.texteditor/src/org/eclipse/ui/internal/findandreplace/overlay/FindReplaceOverlay.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -883,11 +883,13 @@ private void updatePlacementAndVisibility() {
return;
}
if (isInvalidTargetShell()) {
getShell().getDisplay().syncExec(() -> {
close();
setParentShell(targetPart.getSite().getShell());
open();
targetPart.setFocus();
getShell().getDisplay().asyncExec(() -> {
Copy link
Contributor

@Wittmaxi Wittmaxi Jul 16, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was the code leading to a bad bug on windows #1946 (comment)
The difference with the if being inside of the asyncexec block might be enough to not have the overlay be called multiple times, but somehow I doubt we really want to always create a new asynchronous job every time some movement was made

Copy link
Contributor Author

@HeikoKlare HeikoKlare Jul 17, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure whether I get your points correctly.

The bug we had before was a flickering because the close/open combination was executed multiple times. This is properly prevented by re-checking the necessity for doing this close/open within the asynchronous execution block. On Windows, I looks fine:
find_replace_async_new_parent_shell

but somehow I doubt we really want to always create a new asynchronous job every time some movement was made

Why do you assume that the execution is done "very time some movement was made"? The asynchronous execution is only initiated when the target of an open find/replace overlay is moved to another shell, which is a rather seldom user interaction (the condition is checked inside and outside of the execution block). I have debugged the behavior again and found that in this scenario the asynchronous execution is spawned either one or two times, such that at most one execution is "unecessary" (i.e., doing nothing as the condition evaluates to false) on every occurence of that scenario. I find this acceptable compared to some more complex tracking if whether the asynchronous execution was already initiated to avoid doing it a second time. What do you think, @Wittmaxi?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I missed the outer if-clause, sorry! Thank you for clearing this up, I am in favor of merging this PR now.

if (isInvalidTargetShell()) {
close();
setParentShell(targetPart.getSite().getShell());
open();
targetPart.setFocus();
}
});
return;
}
Expand Down
Loading