[Gtk4] Fix layout problems#3331
Open
akurtakov wants to merge 2 commits into
Open
Conversation
On Gtk 4 gtk_widget_hide() resets the widget's allocation to 0x0. If the SWT widget is no longer in the HIDDEN state but visibility hasn't propagated in GTK 4, leave it visible on the GTK side so its allocation (and the propagated allocations of its children) survive. Otherwise children of a Composite that was made visible right before this setBounds call would be left at size 0x0 and miss Resize events. Skip the trailing gtk_widget_hide() on GTK4 when the SWT widget is not in the HIDDEN state, so the allocation survives. GTK3 behaviour is unchanged. Fixes eclipse-platform#3330
Contributor
akurtakov
changed the title
In GTK4, hiding a wigdet resets its allocation to 0x0. When a previously hidden Control is made visible and GTK runs a layout pass, GTK assigns a fresh allocation via natural-size propagation. SWT is not notified of this GTK-driven allocation, so any children that lost their allocation while the control was hidden stay at size 0x0 and never fire SWT.Resize. Override gtk_map in Control so that when GTK maps a widget (after the frame-clock has assigned its new allocation), a deferred parent layout is triggered. This causes SWT to recompute child bounds at the right moment without needing to know the allocation synchronously inside setVisible(). Fixes eclipse-platform#3330
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On Gtk 4 gtk_widget_hide() resets the widget's allocation to 0x0. If the SWT widget is no longer in the HIDDEN state but visibility hasn't propagated in GTK 4, leave it visible on the GTK side so its allocation (and the propagated allocations of its children) survive. Otherwise children of a Composite that was made visible right before this setBounds call would be left at size 0x0 and miss Resize events.
Skip the trailing gtk_widget_hide() on GTK4 when the SWT widget is not in the HIDDEN state, so the allocation survives. GTK3 behaviour is unchanged.
In GTK4, hiding a wigdet resets its allocation to 0x0.
When a previously hidden Control is made visible and GTK runs a layout pass, GTK assigns a fresh allocation via natural-size propagation.
SWT is not notified of this GTK-driven allocation, so any children that lost their allocation while the control was hidden stay at size 0x0 and never fire SWT.Resize.
Override gtk_map in Control so that when GTK maps a widget (after the frame-clock has assigned its new allocation), a deferred parent layout is triggered. This causes SWT to recompute child bounds at the right moment
without needing to know the allocation synchronously inside setVisible().
Fixes #3330