== Planned Features ==
I got annoyed by the static nature of this list which caused brushes that I just tried once or even selected by accident to stick there forever while often used ones kept falling out.
So I figured it gets time for some more options.
After some pondering, I decided to try a bubbling approach. That means, when you use a preset repeatedly, it moves up a position. To avoid unnecessary noise (especially when toggling between the 2 topmost presets), I decided to make them not bubble up right away, but basically set them to "challenge" the position above them, but to actually move past, it needs a second activation.
And because it was trivial to implement, I also added an option to sort by most recently used, which just needs to put every preset back to the top of the list as it gets activated.
Since it was requested on [[https://krita-artists.org/t/brush-history-question/2843 | Krita Artists]] recently, I also want to add a setting for the number of history entries, once the below issue is clarified.
== Open Questions ==
__Configuration GUI__
So far I can't really see a clear concept of how various plugins or dockers in specific handle configuration options. Adding a new sidebar item in the "Configure Krita" dialog for each of them doesn't seem very feasible in the long run, nor does it seem very nice when each docker has a configuration button somewhere where the creator figured it disturbs the least (I can see at least 3 different corners being chosen already, and in this case, it would inevitably make the docker larger, which I want to avoid), so I'd like to have some input on that.
Ideally I'd like one `Docker Settings` page the the Krita settings dialog, with a (dropdown) list to select the docker and the docker provides a configuration widget.
That widget may be available as separate dialog through the docker itself, like with the Advanced Color Selector.
Making it available through a right-click context menu might be an alternative to a button in the docker, but probably not as only way to reach the settings, given that this is not exactly touch-friendly.
__Configuration Implementation__
And on the technical side, it's not very clear if we're supposed to add new members to KisConfig for every new setting, if defaults should be added to `krita/data/kritarc`, and if plugins should use separate KConfigGroups to keep kritarc more organized.
For the sake of testing I use `presethistorySorting` in kritarc:
`presethistorySorting=0` : static (old behavior)
`presethistorySorting=1`: most recent
`presethistorySorting=2` : bubbling