Community
Participate
Working Groups
Please launch attached snippet on Linux (tried Manjaro). The column separators should be one single line over the full height of the table header, but it is interrupted by the text background.
Created attachment 285327 [details] Snippet to reproduce
Created attachment 285328 [details] Screenshot from Manjaro
Created attachment 285329 [details] Screenshot from Manjaro
Created attachment 285430 [details] Zoomed in version of the previous image
Created attachment 285432 [details] Snippet ran on Gnome Wayland Unfortunately I am unable to reproduce this on Gnome. Looking at the code, I don't really see why the background color would be used for a portion of the separator, since the background css is applied only to the buttons.
I'm using Gnome as well. Are there any information I can provide to make you understand what the problem might be?
Are you sure this is the text background, which you set to #414141? The black interruption is clearly looks blacker on my screen and seems to be #393939.
Two more observations just from looking at the code in Table.setHeaderBackground(): * Table.setHeaderBackground() only adds a new style provider. Shouldn't it also remove a previously set provider? Otherwise providers pile up when this is called several times? * According to [1], user CSS can still override this. Could that explain why Paul cannot reproduce? [1] https://developer.gnome.org/gtk3/stable/GtkStyleContext.html#id-1.5.4.10.8
1) Thank you for pointing this out. I have fixed the patch to include a change in which the Tree/Table Column have their own headerButtonCSSProvider which will be reused until the column is disposed. 2) You are right that user CSS can override this. This could affect why I can't see it. If you don't mind testing setting the header background to red, so we can see if the separator is getting the color from the background we are setting or from some other source.
(In reply to Soraphol (Paul) Damrongpiriyapong from comment #9) > 2) You are right that user CSS can override this. This could affect why I > can't see it. If you don't mind testing setting the header background to > red, so we can see if the separator is getting the color from the background > we are setting or from some other source. @Thomas Singer; could you try that? I can't check this; my observations were just from code inspection and inspection of the screenshots. I'm on OS X; have no Linux setup.
(In reply to Soraphol (Paul) Damrongpiriyapong from comment #9) > 1) Thank you for pointing this out. I have fixed the patch to include a > change in which the Tree/Table Column have their own headerButtonCSSProvider > which will be reused until the column is disposed. Where can I find it? It shouldn't be part of the master, yet, right?
(In reply to Thomas Singer from comment #11) > Where can I find it? It shouldn't be part of the master, yet, right? Paul means https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/175592 .
Created attachment 285445 [details] Screenshot with Matcha-light-sea theme
Created attachment 285446 [details] Screenshot with Matcha-light-sea theme without setting colors
Setting env var GTK_THEME to Adwaita shows everything fine, so it looks like a problem with theming the Matcha-light-sea theme.
Is Eclipse forceibly setting the GTK_THEME to Adwaita to avoid such problems?
(In reply to Thomas Singer from comment #16) > Is Eclipse forceibly setting the GTK_THEME to Adwaita to avoid such problems? No we don't but https://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_19.xml#target_environments says: "" With respect to GTK 3 themes: Adwaita theme is guaranteed to work. Eclipse SDK will run with other GTK 3 themes, however we cannot flag these as reference versions without significant community support for testing and/or development of fixes. Bugs that are reproducible only with themes other than Adwaita will be given a lower priority (or may not be fixed at all), compared to bugs which are reproducible on the target environments listed above. "" There are so many themes with a good part of them being half baked that providing support for random one is just unrealistic which led us to add this statement.
