Locked Settings is actually a misnomer to what this feature does. Contrary to the common sense notion that it may make an option or setting non editable, it actually shares that particular option across all presets.
After that rather foggy opening statement, here is what it actually does.
Right Clicking on any of the options with the Link Icon in front of them brings up the menu to “Lock” the option. Once the option is locked, the option will remain constant across all presets.
For example : we locked Brush Tip for the Basic_Circle_Wet preset. Now, even when we are in the Bristles_Wet preset, the Brush Tip is the same. However, the Brush Tip is still editable as before. If we change the Diameter or any other parameter, it will reflect across all presets — even the original one. So we are not really locking the setting, we are sharing it.
Right Clicking on a Locked Option brings up the following menu :
Selecting the “Load Last Selected” option will revert the current preset back to the configuration it had before it got overriden by the Locked/Shared Setting. Whereas “Load Current Setting” will unlock the option, but keep the current configuration with the preset.
This feature is ( or will be?) particularly useful when the user likes a particular configuration for an option, but wants to explore different presets with the same option. So, he/she doesn’t always have to change the Brush Tip or Size Option to his/her preferred configuration — Just Lock it and continue exploring more options 🙂
Now, for how the feature was implemented.
DmitryK introduced me to a new (for me :P) type of design called Proxy Pattern Based Design. The logic was simple — keep a central list of the Options being Locked with their configuration values. This List is accessible via a Global Static Server Class that keeps an object of the List. Now, whenever the paintop widget is required to set the configuration from the Preset Settings to the widget or required to write the configuration from the widget to the Preset Settings, a Proxy object ,generated by the LockedSettings Server, is passed into these functions rather than the original Settings object. The job of the Proxy Object is to make a detour to the Locked Settings Server and check whether any of the Options to be Read/Written from/onto the Widget are saved in the Locked Settings List. For all the Options in that List, the values are borrowed from the List rather than the Preset and passed on to the Widget.
So using this design, I was able to circumvent a lot of problems that I would have had to face if I had kept the Preset and the Widget object in the loop to obtain the Locked Setting Values. I just modified the path between the two by putting a Locked Settings Server in between. So technically, the Preset Object and the Widget don’t even know that there is any such thing known as Locked Settings !!
I am currently working on Cumulative Undo/Redo that will free up Undo Slots in Krita by merging strokes together. More on that in the next post. For now, <lame attempt at humour>since my eye lids are fighting a losing battle against gravity, I may as well log out or work upside down</lame attempt at humour>. Ciao !!