https://bugs.kde.org/show_bug.cgi?id=410948

Albert Astals Cid <aa...@kde.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Latest Commit|                            |https://invent.kde.org/util
                   |                            |ities/rsibreak/commit/44a7c
                   |                            |608beffa95deccec48b83d90b88
                   |                            |68b26ed5
         Resolution|---                         |FIXED

--- Comment #2 from Albert Astals Cid <aa...@kde.org> ---
Git commit 44a7c608beffa95deccec48b83d90b8868b26ed5 by Albert Astals Cid, on
behalf of Roman Azami.
Committed on 10/01/2022 at 21:55.
Pushed by aacid into branch 'master'.

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

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 :)

M  +1    -1    src/rsidock.cpp
M  +1    -4    src/rsidock.h
M  +1    -2    src/rsiwidget.cpp

https://invent.kde.org/utilities/rsibreak/commit/44a7c608beffa95deccec48b83d90b8868b26ed5

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to