Skip to content

Fix timers behaviour when config was[n't] updated

Roman Azami requested to merge romanazami/rsibreak:dont_always_reset_timers into master

Original bug report detailed that when no changes to config were made and OK was pressed the timers still reset everytime.

Method for resetting timers is RSITimer::updateConfig. Upon clicking OK button event "configChanged" is emitted. This event has two subscribers through which we arrive at RSITimer::updateConfig:

  • Three functions deep passageway RSIObject::readConfig -> RSIObject::configureTimer -> m_timer->updateConfig()
  • Direct connect to RSITimer::updateConfig

The second one is problematic, as when "configChanged" is being emitted the argument passed to RSITimer::updateConfig is essentially always true when app is not suspended. Passing true forces reset of timers.

So delete the second one, as it is redundant and will be called through other subscriber without argument and wont force reset.

Upon removing second subscriber resets when config hasn't changed went away. But another issue came up - legitimate timer config changes weren't being applied when clicking OK the first time. Opening config second time and again clicking OK seemed to set the new config values.

After further debugging it seems that another subscriber of "configChanged" - RSIGlobals::slotReadConfig sets RSITimer::m_intervals's new values only after the call to RSITimer::updateConfig was already made.

The fix for this seems to be changing sequence of connect()'s to the event. Although I do not know enough about this observer mechanism to be completely sure that sequence of subcribing is always being respected when events are emitted :)

BUG: 410948

Edited by Roman Azami

Merge request reports