Re-factor BasePreferences to essentially be a wrapper around AppOptions
#18413
Conversation
Snuffleupagus
force-pushed
the
BasePreferences-AppOptions-wrapper
branch
from
e04ac83
to
dc90329
Compare
|
/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/d9dff635667b84d/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/00b7f8245c22a11/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/00b7f8245c22a11/output.txt Total script time: 8.36 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.193.163.58:8877/d9dff635667b84d/output.txt Total script time: 18.96 mins
|
|
/botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @timvandermeij received. Current queue size: 0 Live output at: http://54.241.84.105:8877/56022a01d32f834/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/56022a01d32f834/output.txt Total script time: 1.03 mins Published |
Snuffleupagus
force-pushed
the
BasePreferences-AppOptions-wrapper
branch
from
dc90329
to
76af87d
Compare
…tions` In the MOZCENTRAL build the `BasePreferences` class is almost unused, since it's only being used to initialize and update the `AppOptions` which means that theoretically we could move the relevant code there. However for the other build targets (e.g. GENERIC and CHROME) we still need to keep the `BasePreferences` class, although we can re-factor things to move the necessary validation inside of `AppOptions` and thus simplify the code and reduce duplication. The patch also moves the event dispatching, for changed preference values, into `AppOptions` instead.
Snuffleupagus
force-pushed
the
BasePreferences-AppOptions-wrapper
branch
from
76af87d
to
d9f0ec0
Compare
|
Thank you for doing this; it's a nice simplification! |
In the MOZCENTRAL build the
BasePreferencesclass is almost unused, since it's only being used to initialize and update theAppOptionswhich means that theoretically we could move the relevant code there.However for the other build targets (e.g. GENERIC and CHROME) we still need to keep the
BasePreferencesclass, although we can re-factor things to move the necessary validation inside ofAppOptionsand thus simplify the code and reduce duplication.The patch also moves the event dispatching, for changed preference values, into
AppOptionsinstead.