Consistently dispatch events, if needed, when setting AppOptions #18495
Conversation
|
/botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/08bc7d52569a0bb/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/08bc7d52569a0bb/output.txt Total script time: 1.75 mins Published |
Currently we'll only dispatch events, for the options that support it, when updating preferences. Since this could potentially lead to inconsistent behaviour, let's avoid any future surprises by *always* dispatching events regardless of how the relevant option is being changed. Obviously we should then also dispatch events in `AppOptions.set`, and to avoid adding even more duplicated code this method is changed into a wrapper for `AppOptions.setAll`. While this is technically a tiny bit less efficient I don't think it matters in practice, since outside of development- and debug-mode `AppOptions.set` is barely used.
Snuffleupagus
force-pushed
the
AppOptions-setAll-EVENT_DISPATCH
branch
from
5a9d4c3
to
58c7b5b
Compare
|
/botio integrationtest |
From: Bot.io (Linux m4)ReceivedCommand cmd_integrationtest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/a3448461d1560c9/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_integrationtest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.193.163.58:8877/e945d87146cc0d6/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/a3448461d1560c9/output.txt Total script time: 11.06 mins
|
From: Bot.io (Windows)FailedFull output at http://54.193.163.58:8877/e945d87146cc0d6/output.txt Total script time: 19.95 mins
|
|
/botio integrationtest |
From: Bot.io (Windows)ReceivedCommand cmd_integrationtest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.193.163.58:8877/e9dae332131dc80/output.txt |
From: Bot.io (Linux m4)ReceivedCommand cmd_integrationtest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/f8cbbb759b2a507/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/f8cbbb759b2a507/output.txt Total script time: 10.93 mins
|
From: Bot.io (Windows)FailedFull output at http://54.193.163.58:8877/e9dae332131dc80/output.txt Total script time: 18.19 mins
|
Currently we'll only dispatch events, for the options that support it, when updating preferences. Since this could potentially lead to inconsistent behaviour, let's avoid any future surprises by always dispatching events regardless of how the relevant option is being changed.
Obviously we should then also dispatch events in
AppOptions.set, and to avoid adding even more duplicated code this method is changed into a wrapper forAppOptions.setAll.While this is technically a tiny bit less efficient I don't think it matters in practice, since outside of development- and debug-mode
AppOptions.setis barely used.