Implement new settings item component#36055
Conversation
Can
It'd be a solution that: is plainly declarative, resides next to the control you'd expect it to reside in (and not its subsection for weird reasons), involves no virtual magic. |
Nice idea, seems to work perfectly in my mind as well. Have applied. |
|
Visually I'm pretty happy with how things are looking. I think you should add a tooltip to the revert button "Revert to default". |
|
|
||
| #region Filtering | ||
|
|
||
| public const string CLASSIC_DEFAULT_SEARCH_TERM = @"has-classic-default"; |
There was a problem hiding this comment.
passing remark, no action required: was hoping to see something less of an utter hack job to replace this but alright
There was a problem hiding this comment.
Had same thoughts but looking at what ScreenBehaviour faces I think it's just fine the way it is. If anything, maybe we could have a SearchPredicate function in SearchContainer which, rather than filtering by a search term, it filters by giving each Drawable to that predicate and returning true/false to filter. But I'll leave that for another day.
1e531b9 to
f273163
Compare
First step towards #36040, and a solution to a long-standing issue with the code quality of the existing
SettingsItemand its entire hierarchy of subclasses.Opening notes:
New version
The new version
SettingsItemV2utilizes composition (as proposed by @bdach and @peppy) to wrap the UI control in a component that offers a revert-to-default button and filtering functionality. The class is sealed given its design.Example usage:
Drawbacks
There are few drawbacks worth mentioning from this approach, one which has already been discussed, and another I kept until opening this PR so it's easier to discuss it code-wise.
SettingsItemV2cannot be aware of any bindableThis necessitated the presence of a non-generic
IFormControlinterface, implemented across all form controls, exposing basic bindable interaction API forSettingsItemV2to utilize.This has been discussed already and we've agreed to push forward with the interface above. I'm hoping for a day where o!f bindables directly support non-generic interaction, but I don't expect that happening any time soon due to the core idea of
IBindableinterfaces being readonly (making a function likeSetDefaultviolate rules if placed there).SettingsItemV2cannot store "classic" default valuesDue to
SettingsItemV2not being generic and not support applying arbitrary values to the underlying wrapped control, this feature is impossible to implement withinSettingsItemV2.My initial approach was to take this feature completely away fromSettingsItemV2and into where each settings item is instantiated (i.e.SettingsSubsection). However, part of this feature is filtering all settings based on those who have a classic default value set, thereforeSettingsItemV2must have aHasClassicDefaultflag present in order to feed it to its filter terms.I've sat around for a bit thinking about any way to approach this, but no bright ideas came to mind. So I've bit the bullet and kept the flag, expecting each settings declaration inSettingsSubsectionto set the flag, then override a newApplyClassicDefaultsmethod to overwrite all relevant settings in the subsection to their classic defaults.Need feedback on this. I would ideally want an approach which takesHasClassicDefaultaway fromSettingsItemV2altogether.This has been addressed by the suggestion in #36055 (comment).
Sample implementation
Lastly, to give a full idea of how
SettingsItemV2would transform the coding structure of existing settings, below is the diff ofLayoutSettingsalone, the heaviest settings subsection I found code-wise:Sample implementation