New find/replace overlay broken under wayland #1447
Comments
iloveeclipse
added
Wayland
Linux/GTK
66 tasks
|
@jonahgraham @sratz That might be interesting for the IDE WG to look into as it will be a problem for users on latest Linux distros |
|
I quickly reproduced the issue on WSL using Wayland. At least one reason seems to be this: Setting the shell's location (the one of the find/replace overlay shell) does not work, as also documented here: #790 (comment) This means, the GTK |
|
We show a notification popup to users on first usage of the find/replace overlay to switch back to the existing find/replace dialog. This would give them the chance to easily switch to existing UI (they can of course still switch the UI in the preferences later on). |
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Sep 7, 2024
The FindReplaceOverlay currents registers a paint listener to the target in order to reposition itself upon move or resize events of the parent (paint events subsume resize and move events). This has two drawbacks: 1. The update is performed too often, as paint events happen more often than move or resize events 2. Due to limitations in Wayland, repositioning the overlay does not work there. A combination of processed repaint events and failing position updates even leads to the shell contents moving out of the shell. This change replaces the repaint listener with a move and resize listener. In consequence, less (unnecessary) updates of the overlay's position and size are executed and on Wayland at least the shell contents do not move out of the window anymore. Contributes to eclipse-platform/eclipse.platform.swt#1447
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Sep 7, 2024
The FindReplaceOverlay currents registers a paint listener to the target in order to reposition itself upon move or resize events of the parent (paint events subsume resize and move events). This has two drawbacks: 1. The update is performed too often, as paint events happen more often than move or resize events 2. Due to limitations in Wayland, repositioning the overlay does not work there. A combination of processed repaint events and failing position updates even leads to the shell contents moving out of the shell. This change replaces the repaint listener with a move and resize listener. In consequence, less (unnecessary) updates of the overlay's position and size are executed and on Wayland at least the shell contents do not move out of the window anymore. Contributes to eclipse-platform/eclipse.platform.swt#1447
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Sep 7, 2024
The FindReplaceOverlay currently registers a paint listener to the target in order to reposition itself upon move or resize events of the parent (paint events subsume resize and move events). This has two drawbacks: 1. The update is performed too often, as paint events happen more often than move or resize events 2. Due to limitations in Wayland, repositioning the overlay does not work there. A combination of processed repaint events and failing position updates even leads to the shell contents moving out of the shell. This change replaces the repaint listener with a move and resize listener. In consequence, less (unnecessary) updates of the overlay's position and size are executed and on Wayland at least the shell contents do not move out of the window anymore. Contributes to eclipse-platform/eclipse.platform.swt#1447
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Sep 7, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there. This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Sep 7, 2024
The FindReplaceOverlay currently registers a paint listener to the target in order to reposition itself upon move or resize events of the parent (paint events subsume resize and move events). This has two drawbacks: 1. The update is performed too often, as paint events happen more often than move or resize events 2. Due to limitations in Wayland, repositioning the overlay does not work there. A combination of processed repaint events and failing position updates even leads to the shell contents moving out of the shell. This change replaces the repaint listener with a move and resize listener. In consequence, less (unnecessary) updates of the overlay's position and size are executed and on Wayland at least the shell contents do not move out of the window anymore. Contributes to eclipse-platform/eclipse.platform.swt#1447
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Sep 8, 2024
The FindReplaceOverlay currently registers a paint listener to the target in order to reposition itself upon move or resize events of the parent (paint events subsume resize and move events). This has two drawbacks: 1. The update is performed too often, as paint events happen more often than move or resize events 2. Due to limitations in Wayland, repositioning the overlay does not work there. A combination of processed repaint events and failing position updates even leads to the shell contents moving out of the shell. This change replaces the repaint listener with a move and resize listener. In consequence, less (unnecessary) updates of the overlay's position and size are executed and on Wayland at least the shell contents do not move out of the window anymore. Contributes to eclipse-platform/eclipse.platform.swt#1447
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Sep 8, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there. This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Sep 9, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there. This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Sep 11, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Sep 12, 2024
The FindReplaceOverlay currently registers a paint listener to the target in order to reposition itself upon move or resize events of the parent (paint events subsume resize and move events). This has two drawbacks: 1. The update is performed too often, as paint events happen more often than move or resize events 2. Due to limitations in Wayland, repositioning the overlay does not work there. A combination of processed repaint events and failing position updates even leads to the shell contents moving out of the shell. This change replaces the repaint listener with a move and resize listener. In consequence, less (unnecessary) updates of the overlay's position and size are executed and on Wayland at least the shell contents do not move out of the window anymore. Contributes to eclipse-platform/eclipse.platform.swt#1447
HeikoKlare
added a commit
to eclipse-platform/eclipse.platform.ui
that referenced
this issue
Sep 12, 2024
The FindReplaceOverlay currently registers a paint listener to the target in order to reposition itself upon move or resize events of the parent (paint events subsume resize and move events). This has two drawbacks: 1. The update is performed too often, as paint events happen more often than move or resize events 2. Due to limitations in Wayland, repositioning the overlay does not work there. A combination of processed repaint events and failing position updates even leads to the shell contents moving out of the shell. This change replaces the repaint listener with a move and resize listener. In consequence, less (unnecessary) updates of the overlay's position and size are executed and on Wayland at least the shell contents do not move out of the window anymore. Contributes to eclipse-platform/eclipse.platform.swt#1447
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Sep 16, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there. This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Sep 16, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099
|
For anyone facing this, the workaround mentioned by Heiko is to open Preferences > General > Editors > Text editors and untick "Use find/replace overlay". |
|
FYI, you can update from https://download.eclipse.org/eclipse/updates/4.34-I-builds/ Also, after M1 is completed next week Thursday morning you can update from https://download.eclipse.org/releases/milestone/ Of course these things will update many things to current development-in-progress versions which you may not desire. |
|
In M1, the overlay should not be as broken as before when using Wayland anymore. The contents should not "disappear" / move out of the window anymore, but still the overlay itself will be misplaced. I hope that I can soon find a solution for the remaining issues of the PR to completely fix it (eclipse-platform/eclipse.platform.ui#2254). |
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Sep 28, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Sep 28, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Oct 1, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Oct 2, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Oct 2, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Oct 2, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Oct 2, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Oct 2, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Oct 3, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Oct 3, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Oct 3, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Oct 3, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099 Fixes eclipse-platform#2246
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Oct 3, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099 Fixes eclipse-platform#2246
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Oct 10, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099 Fixes eclipse-platform#2246
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Oct 10, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099 Fixes eclipse-platform#2246
HeikoKlare
added a commit
to HeikoKlare/eclipse.platform.ui
that referenced
this issue
Oct 11, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099 Fixes eclipse-platform#2246
HeikoKlare
added a commit
to eclipse-platform/eclipse.platform.ui
that referenced
this issue
Oct 11, 2024
The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes #2099 Fixes #2246
praveen-skp
pushed a commit
to praveen-skp/eclipse.platform.ui
that referenced
this issue
Oct 14, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099 Fixes eclipse-platform#2246
lathapatil
pushed a commit
to lathapatil/eclipse.platform.ui
that referenced
this issue
Oct 21, 2024
The FindReplaceOverlay currently registers a paint listener to the target in order to reposition itself upon move or resize events of the parent (paint events subsume resize and move events). This has two drawbacks: 1. The update is performed too often, as paint events happen more often than move or resize events 2. Due to limitations in Wayland, repositioning the overlay does not work there. A combination of processed repaint events and failing position updates even leads to the shell contents moving out of the shell. This change replaces the repaint listener with a move and resize listener. In consequence, less (unnecessary) updates of the overlay's position and size are executed and on Wayland at least the shell contents do not move out of the window anymore. Contributes to eclipse-platform/eclipse.platform.swt#1447
lathapatil
pushed a commit
to lathapatil/eclipse.platform.ui
that referenced
this issue
Oct 21, 2024
…-platform#2099 The FindReplaceOverlay is currently realized as a separate shell (more precisely, a JFace Dialog), which is placed at a proper position on top of the workbench shell. This has some drawback: - It has to manually adapt to movements of the parent shell or the target part/widget - It has to manually hide and show depending on visibility changes of the target part/widget - It does not follow events of the target immediately, i.e., movements are always some milliseconds behind, minimize/maximize operations/animations are not synchronous etc. - It does not locate properly when the platform uses Wayland, as manual shell positioning is not possible there This change replaces the dialog-based implementation of the FindReplaceOverlay with an in-place composite-based implementation. A composite is created in the target widget and placed relative to this composite. In consequence, the overlay automatically follows all move, resize, hide/show operations of the target widget. Fixes eclipse-platform/eclipse.platform.swt#1447 Fixes eclipse-platform#2099 Fixes eclipse-platform#2246
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Trying to use new find/replace under Wayland is almost entirely impossible, It constantly moves and hides. Just watch the video
Screencast.from.2024-09-05.15-02-10.mp4
Environment:
Additional OS info (e.g. OS version, Linux Desktop, etc)
Fedora 40, Gnome on Wayland
JRE/JDK version
Java 23
The text was updated successfully, but these errors were encountered: