Community
Participate
Working Groups
Oomphs preference recorder does not apply correctly theme changes. To reproduce: 1.) Install and activate preference recorder 2.) In a new workspace switch your theme (either to dark or to light) 3.) Open another workspace which used the opposite theme -> theme gets a weird combination of white and dark 4.) Restart Eclipse for the messy looking workspace -> theme gets correctly applied
One might argue that such a restart shouldn't be required in the first place, but I don't realistically expect that platform and the stack built on it to accommodate such an expectation. :-P I'll bet though that if one does this same process manually, i.e., import preferences from a preference file that the platform also doesn't suggest that a restart is needed... Please contradict me if I lose this bet. :-P In any case, the preference task implementation has no idea what any of the preferences actually mean, so knowledge about this specific preference requiring a restart in order to work properly is something that would need to be hard coded either in the task itself or via some extended information (an annotation) perhaps on the task; in the latter case, the preference recorder would still need to create the annotation so there would still be hard-coded logic for this specific preference somewhere in the code... I'll mark this as an enhancement given that this is asking for specific new handling for this one specific preference.
The platform does not require a restart after theme switch (if Oomph is not present). We still warn about it but at least on Linux dynamic theme switching works fine without restart.
I know the platform requires a restart for this preference and tells you that that when you use the preference dialog. The question was whether the platform does anything helpful when the user manually imports preferences?
(In reply to Ed Merks from comment #3) > I know the platform requires a restart for this preference and tells you > that that when you use the preference dialog. No, it does not required a restart at theme switching. We used to require that and therefore we implemented the warning. The only reason why this warning is left on, is that certain SWT widgets might still have bugs so that they do not react to our restyling request. To test this: Preference -> General -> Appearance. Switch from Light to Dark -> Should work fine without restart on Mac. > The question was whether the > platform does anything helpful when the user manually imports preferences? I almost never did import preference but I guess preference listeners are triggered during this import? If yes, we could register a preference listener for theme changes, which should also help Oomph. Please confirm, in this case, I move this bug to platform.
(In reply to Lars Vogel from comment #4) > (In reply to Ed Merks from comment #3) > > I know the platform requires a restart for this preference and tells you > > that that when you use the preference dialog. > > No, it does not required a restart at theme switching. We used to require > that and therefore we implemented the warning. The only reason why this > warning is left on, is that certain SWT widgets might still have bugs so > that they do not react to our restyling request. > Okay, well the warning sure made me believe that it's necessary. > To test this: Preference -> General -> Appearance. Switch from Light to Dark > -> Should work fine without restart on Mac. > > > The question was whether the > > platform does anything helpful when the user manually imports preferences? > > I almost never did import preference but I guess preference listeners are > triggered during this import? Yes, preference changes trigger listeners. But often the underlying assumption as that preference only change via the dialog such that there are no listeners. That of course doesn't help when one imports preferences or uses Oomph's preference tasks. > If yes, we could register a preference > listener for theme changes, which should also help Oomph. Please confirm, in > this case, I move this bug to platform. If a restart really isn't required then yes, better that the platform listens for preferences changes such that manual imports or any other mechanism (Oomph's preference tasks) that change the value will have the same effect as changing it via the dialog.
Thanks Ed, moving to platform. We should add a preference listener to the theme change.
Please set a target when you plan to work on this bug.
Andrew, something for you?
(In reply to Lars Vogel from comment #8) > Andrew, something for you? I'm not 100% sure I understand what needs to be done here. Does a preference change event need to be fired when the theme changes?
(In reply to Andrew Obuchowicz from comment #9) > (In reply to Lars Vogel from comment #8) > > Andrew, something for you? > > I'm not 100% sure I understand what needs to be done here. > > Does a preference change event need to be fired when the theme changes? Vice-versa, if the preference changes and theme event needs to get triggered.
(In reply to Lars Vogel from comment #10) > (In reply to Andrew Obuchowicz from comment #9) > > (In reply to Lars Vogel from comment #8) > > > Andrew, something for you? > > > > I'm not 100% sure I understand what needs to be done here. > > > > Does a preference change event need to be fired when the theme changes? > > Vice-versa, if the preference changes and theme event needs to get triggered. If I understand the problem correctly, we want to make sure that when any preference change that would require re-theming, the theming engine should be triggered. How would one determine which preference changes require a theme event to be triggered? I imagine one's that affect colors would require a theme change, many examples can be seen in https://github.com/AObuchow/Eclipse-Spectrum-Theme/blob/master/com.aobuchow.themes.spectrum/css/preference_styles.css#L142 But is there a way to filter for these types of preferences? I haven't actually looked into how these colore-related preference objects are implemented.
Mass change to 4.19 M1, please update the target if you have other plans.
Mass move 4.19 M1 bugs to M3
Removing milestone from 4.19 M3 to 4.19, please re-target accordingly.
Mass move out of 4.19
Mass Move out of 4.20
Mass Move out of 4.21
Mass Move out of 4.22
