eclipse.platform.swt icon indicating copy to clipboard operation
eclipse.platform.swt copied to clipboard

trims.prefs occasionally generates bogus trim sizes

Open ptziegler opened this issue 4 months ago • 4 comments

Describe the bug

Every now and then, the trims.prefs size is filled with number that are too big. As a result, shells end up being way too small and with major portions being cut off.

Additionally, the sizes that are then reported by SWT are blatantly wrong and differ from both the expected, as well as the physical size of the shell.

Note: This all appeared within the same session. I didn't change the theme or anything like that.

To Reproduce

This only happens sporadically and I haven't found a way yet to reliably reproduce this problem. Though I think this might be caused when debugging SWT code.

Expected behavior

The preference file should store reasonable values.

Screenshots

Image

Environment:

  1. Select the platform(s) on which the behavior is seen:
    • [ ] All OS
    • [ ] Windows
    • [x] Linux
    • [ ] macOS
  1. Additional OS info (e.g. OS version, Linux Desktop, etc)

Kubuntu 24.04

  1. JRE/JDK version

Version since

Happened with the 2025-09 RC1, but will likely also occur in older version.

Workaround (or) Additional context

The .swt folder needs to be purged.

ptziegler avatar Aug 21 '25 19:08 ptziegler

I just cleared the .swt folder and it's better, but still not accurate...

Image

Are there other properties that need to be removed?

ptziegler avatar Aug 21 '25 19:08 ptziegler

See also https://github.com/eclipse-platform/eclipse.platform.swt/pull/1165 and https://github.com/eclipse-platform/eclipse.platform.swt/issues/1168.

iloveeclipse avatar Aug 22 '25 02:08 iloveeclipse

After some further testing, the problem seems to appear when calling shell.setSize(), before shell.setVisible()/shell.open() and then only when both the width or the height are smaller than or equal to 334 pixels. For larger values, the problem doesn't appear.

As long as the shell is smaller, calling getSize() always returns exactly (206, 229). The size (200, 200) is returned by the call to gtk_widget_get_allocation and the remaining offset is the actual trim of the shell.

The difference between this size and the requested size can then end up in the trims.prefs.

ptziegler avatar Aug 22 '25 18:08 ptziegler

The size (200, 200) is returned by the call to gtk_widget_get_allocation and the remaining offset is the actual trim of the shell.

A similar behavior was already reported with Bug 465280 - [GTK3] OS.gtk_widget_get_allocation returns (0,0) for invisible controls

The corresponding fix can be found here: https://github.com/eclipse-platform/eclipse.platform.swt/blob/1eb32bceefec6b60436775dde88ef7391ecebcc7/bundles/org.eclipse.swt/Eclipse%20SWT/gtk/org/eclipse/swt/widgets/Control.java#L1135-L1163

Because Shell overrides setBounds(...), this section is never called.

ptziegler avatar Aug 22 '25 18:08 ptziegler