On Thu, 15 May 2025 18:56:14 GMT, Michael Strauß <mstra...@openjdk.org> wrote:
>> Some platform preference changes can trigger the emission of multiple >> notifications. For example, when switching from a high-contrast theme on >> Windows to the regular theme, the following notifications are emitted (log >> can be viewed in `PlatformPreferencesChangedTest`): >> >> >> changed: >> Windows.UIColor.Accent=0x0078d4ff >> Windows.SysColor.COLOR_HIGHLIGHTTEXT=0xffffffff >> Windows.SysColor.COLOR_WINDOW=0xffffffff >> Windows.UIColor.AccentLight1=0x0091f8ff >> Windows.SysColor.COLOR_3DFACE=0xf0f0f0ff >> Windows.SysColor.COLOR_HOTLIGHT=0x0066ccff >> Windows.SysColor.COLOR_WINDOWTEXT=0x000000ff >> Windows.SysColor.COLOR_BTNTEXT=0x000000ff >> Windows.UIColor.Foreground=0x000000ff >> Windows.UIColor.AccentDark1=0x0067c0ff >> Windows.UIColor.Background=0xffffffff >> Windows.UIColor.AccentLight3=0x99ebffff >> Windows.UIColor.AccentLight2=0x4cc2ffff >> Windows.SysColor.COLOR_GRAYTEXT=0x6d6d6dff >> Windows.SysColor.COLOR_HIGHLIGHT=0x0078d7ff >> Windows.UIColor.AccentDark2=0x003e92ff >> Windows.UIColor.AccentDark3=0x001a68ff >> >> changed: >> -Windows.SPI.HighContrastColorScheme >> Windows.SPI.HighContrast=false >> >> changed: >> Windows.UIColor.Foreground=0xffffffff >> Windows.UIColor.Background=0x000000ff >> >> >> Notably, the values for Windows.UIColor.Foreground/Background are >> inconsistent between the notifications (although they are eventually >> correct). In general, only a single notification should be emitted that >> includes all of the changed preferences. >> >> This artifact is only visible on Windows. The reason is that changing some >> system settings (like high-contrast theme) causes a number of different >> window messages to be sent to the application. We should wait for all window >> messages to come in, and then aggregate all of the changed preferences into >> a single notification. >> >> In order to minimize the delay between changing a system setting and sending >> out the notification in JavaFX, the implementation only waits when >> instructed to do so by the native toolkit. This allows us to instantly send >> out notifications for most changes, but selectively wait a bit for changes >> where the native toolkit knows that more changes might be coming in. > > Michael Strauß has updated the pull request incrementally with one additional > commit since the last revision: > > simplified DelayedChangedAggregator I'm in favor of abstracting this away as good as possible, i.e. trying to aggregate such events if some sufficiently universal timing parameters (or something better than time-based logic) can be found. As an application developer I often choose javafx especially because it keeps OS-implementation dependent behavior to a minimum and reduces the likelihood of me "using things the wrong way", like having inconsistent states that might need to be handled. And who knows what the next version of windows will do... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1810#issuecomment-2884867051
