Skip to content

[Gtk] Fix Tree preferred size becoming invisible after style toggle#3309

Open
akurtakov wants to merge 1 commit into
eclipse-platform:masterfrom
akurtakov:3025
Open

[Gtk] Fix Tree preferred size becoming invisible after style toggle#3309
akurtakov wants to merge 1 commit into
eclipse-platform:masterfrom
akurtakov:3025

Conversation

@akurtakov
Copy link
Copy Markdown
Member

When a Tree with no explicit columns is laid out with SWT.DEFAULT size hints (e.g. GridData(SWT.DEFAULT, SWT.DEFAULT)), the GTK preferred-size call on the not-yet-rendered GtkTreeView returns width 0. The resulting zero-width allocation triggers the ZERO_WIDTH hide path, making the widget invisible.

When a Tree with no explicit columns is laid out with SWT.DEFAULT
size hints (e.g. GridData(SWT.DEFAULT, SWT.DEFAULT)), the GTK
preferred-size call on the not-yet-rendered GtkTreeView returns width 0.
The resulting zero-width allocation triggers the ZERO_WIDTH hide path,
making the widget invisible.
@akurtakov
Copy link
Copy Markdown
Member Author

Fixes #3025

@akurtakov akurtakov self-assigned this May 15, 2026
@akurtakov
Copy link
Copy Markdown
Member Author

This is alternative fix for a similar problem to https://bugs.eclipse.org/bugs/show_bug.cgi?id=465056 but more dynamic. I'll switch Table to this approach too when we open next stream.

@github-actions
Copy link
Copy Markdown
Contributor

Test Results (linux)

   94 files  ±0     94 suites  ±0   15m 11s ⏱️ +29s
4 597 tests ±0  4 373 ✅ ±0  224 💤 ±0  0 ❌ ±0 
3 383 runs  ±0  3 308 ✅ ±0   75 💤 ±0  0 ❌ ±0 

Results for commit 7d2ce46. ± Comparison against base commit 7f9089e.

Copy link
Copy Markdown
Contributor

@HeikoKlare HeikoKlare left a comment

Choose a reason for hiding this comment

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

I can reproduce the issue reported in #3025 and can confirm that this change fixes the issue. I've tested on a WSL system.
The code itself also looks functionally sound to me. I just wonder if this iteration of tree items at OS level may have a performance impact. I remember mentions of performance issues of trees on GTK in the past. And we are currently investigating some issues on Windows where retrieving tree items from the OS is very expensive, such that we try to replace the code with the usage of SWT metadata.

In case we are sure there is no risk of performance issue with this, I leave it up to your judgement whether it is still safe to do for RC1.

@akurtakov
Copy link
Copy Markdown
Member Author

In theory this PR can introduce performance costs, but only in a very specific scenario: a single‑column Tree with a very large number of root items (2K+), and only when GTK reports width = 0. I haven't seen such case in the wild.

@akurtakov
Copy link
Copy Markdown
Member Author

@iloveeclipse As https://bugs.eclipse.org/bugs/show_bug.cgi?id=465056 was reported by you and this one is almost identical wdyt, should we push it for RC1?

@iloveeclipse
Copy link
Copy Markdown
Member

I would wait for 4.41, it is not a recent regression.

Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

Fixes a GTK-specific issue where a Tree with no explicit columns and SWT.DEFAULT size hints could compute a preferred width of 0 (because the GtkTreeView had not yet been rendered), causing the ZERO_WIDTH hide path to make the widget invisible. The fix computes the width directly from cell renderers of root items as a fallback.

Changes:

  • In Tree.computeSizeInPixels, when wHint == SWT.DEFAULT, native size.x == 0, and no explicit columns exist, iterate the root items and use calculateWidth on the first column to derive a non-zero preferred width.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants