Community
Participate
Working Groups
There is code in Display.signalProc() that tries to re-initialize system colors if system theme changes. However, it doesn't get called when theme actually changes, resulting in some controls updating their colors, but many backgrounds staying with the old color from theme loaded at startup. Seems to be broken for many SWT releases already. This is especially prevalent when changing between Light/Dark themes in Gnome/Ubuntu 20.04. I am using SWT for my own app (without JFace): https://angryip.org
This has never been implemented. I agree it's good idea to reset the colors. Do you want to try providing a patch ?
This is required to have proper dark theme support on Linux. See the Bug 563684.
(In reply to Amit Mendapara from comment #2) > This is required to have proper dark theme support on Linux. See the Bug > 563684. Amit, can you provide a Gerrit?
(In reply to Lars Vogel from comment #3) > (In reply to Amit Mendapara from comment #2) > > This is required to have proper dark theme support on Linux. See the Bug > > 563684. > > Amit, can you provide a Gerrit? I worked on a GTK specific solution by listening to "notify::gtk-application-prefer-dark-theme" signal on GtkSettings with Display.signalProc() as callback. What could be the proper way to do it for all supported platforms?
As it's Linux/GTK specific, it should be acceptable. I will provide gerrit soon.
New Gerrit change created: https://git.eclipse.org/r/163821
Gtk specific solution should be fine here. As we are in the 4.16 freeze this may have to wait 2 weeks.
(In reply to Eclipse Genie from comment #6) > New Gerrit change created: https://git.eclipse.org/r/163821 This change can lead to following error: org.eclipse.swt.SWTException: Graphic is disposed at org.eclipse.swt.SWT.error(SWT.java:4723) at org.eclipse.swt.SWT.error(SWT.java:4638) at org.eclipse.swt.SWT.error(SWT.java:4609) at org.eclipse.swt.graphics.Color.getRGB(Color.java:323) at org.eclipse.ui.themes.ColorUtil.getSystemColor(ColorUtil.java:137) at org.eclipse.ui.themes.ColorUtil.process(ColorUtil.java:48) at org.eclipse.ui.themes.ColorUtil.getColorValue(ColorUtil.java:156) at org.eclipse.ui.internal.themes.ColorDefinition.getValue(ColorDefinition.java:111) at org.eclipse.ui.internal.themes.ThemeElementHelper.installColor(ThemeElementHelper.java:287) at org.eclipse.ui.internal.themes.ThemeElementHelper.populateRegistry(ThemeElementHelper.java:184) at org.eclipse.ui.internal.themes.WorkbenchThemeManager.updateThemes(WorkbenchThemeManager.java:176) at org.eclipse.ui.internal.themes.WorkbenchThemeManager.lambda$1(WorkbenchThemeManager.java:147) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5686) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5678) at org.eclipse.swt.widgets.Display.runSettings(Display.java:5008) The code in question "WorkbenchThemeManager.updateThemes" seems too old and related to Windows. We can omit "sendEvent" from "Display.runSettings" but I don't know the purpose of emitting that event.
The code in question is very old fix for the Bug 19229 and looks like Windows specific.
Hello, I have tried testing the patch on Linux and haven't found a difference in behavior when I change the system theme through gnome-tweaks. I set a breakpoint at the callback function as well to see if the signal was emitted and found that it is not. Am I testing this correctly, if so please give me some help. Thanks!
(In reply to Soraphol (Paul) Damrongpiriyapong from comment #10) > Hello, I have tried testing the patch on Linux and haven't found a > difference in behavior when I change the system theme through gnome-tweaks. > I set a breakpoint at the callback function as well to see if the signal was > emitted and found that it is not. I am not sure whether we can listen to system sent signal. > Am I testing this correctly, if so please give me some help. Thanks! Need to test with the changes of bug 563684. Apply the gerrit https://git.eclipse.org/r/163800 to eclipse.platform.ui and test it along with eclipse.platform.swt.
Any update on your testing, Paul?
Hello, I have just gotten around to looking at this again. I have done what Amit asked me to do. (apply the patch from platform as well). Nothing has changed from my previous comment. My question is what is supposed to happen when I apply this patch? When I change the system theme in GNOME-tweaks, the signalProc function is not called as suggested by OS.g_signal_connect(GTK.gtk_settings_get_default (), OS.notify_theme_change, signalProc, STYLE_UPDATED);
(In reply to Soraphol (Paul) Damrongpiriyapong from comment #13) > Hello, I have just gotten around to looking at this again. I have done what > Amit asked me to do. (apply the patch from platform as well). Nothing has > changed from my previous comment. > > My question is what is supposed to happen when I apply this patch? When I > change the system theme in GNOME-tweaks, the signalProc function is not > called as suggested by > > OS.g_signal_connect(GTK.gtk_settings_get_default (), OS.notify_theme_change, > signalProc, STYLE_UPDATED); I don't know if this api can be used to trap system sent signals. The signal is called on eclipse startup (soon after display is created) or when we change eclipse theme. This patch is required to re-initialize system colors when running eclipse with dark theme under light system (gnome) theme or vice versa. To see the effect, apply https://git.eclipse.org/r/163800 patch and run eclipse as I mentioned in previous comment. If you run the eclipse with only https://git.eclipse.org/r/163800 patch and not this one, you will see wrong colors.
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/163821 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=12bab54459bd5e269251cdaaee5a898b24f38b6a
Can this bug be closed ? otherwise please re-target.
Yes, it can be closed. Working fine with the fix.
