Preset widgets refactoring

[Boudewijn Rempt]

On Wed, 1 Jul 2015, Stefano Bonicatti wrote:

> 1) We have issues with widgets presets being too smart and fighting each other when selecting a preset, especially between the preset docker, preset popup and the preset strip.
> 
> 2) We don't distinguish call paths that comes from or signals that are emitted due to UI or non UI events.
> This leads to problems because in some cases creates loops (that are dealt with but in a way that creates other functionality issues).
> We should split these paths by using different functions and different signals and we should be sure that one can't trigger the other.
> 
> 3) We have generic signals (canvasResourceChanged) that are used to keep track of specific things (presets), but we don't check if this specific thing is really changed and we do
> unnecessary work that might also create functionality issues.
> 
> 4) We have reuse of signals beyond scope, like resourceRemoved to force an update of the resource model, but this triggers code that it shouldn't be called in some cases. 
> We need to have specific signals for specific operations.
> 
> 5) We have fighting occurring between higher classes and base classes too, about the resource selection (preset widgets fighting with KoResourceItemChooser etc).
> We probably should have base classes that are more dumb than we have now.
> 
> Solution: a part from the ones given in the list, having a central class that deals with keeping track of the current preset and talking with the widgets avoiding loops or avoiding to
> call widgets function due to signal sent by those same widgets, i think, solves this issues.

Well, that's what the canvas resource provider classes were meant for. It 
got really messy when we decided to take the resource classes to the 
calligra base library level, I think.

> Widgets should only take input and display results, they will only be able to directly affect this central class through signals and only very indirectly and with the necessary controls,
> the other widgets.
> 
> This is already quite long so i will end this here, but is necessary to understand the need of the refactoring and also the fact that it can't really be done in steps.. because there are
> a lot of places that are failing and they are all connected so we need to fix all those together.
> Next step from me is to obtain a sort of graph of interactions to have in front of the eyes what currently happens, between all the classes involved, when a preset is selected, or what
> happens when something generate a preset selection.

Right now, I would actually prefer to take a deep breath, forget about 
the existing code and the way it works and start with a fresh design. When 
the design is done, I'd check to see whether any existing code maps to it, 
and then start re-using code where possible, and dropping it where 
necessary.

I think we have a bunch more problems with the resource loading, 
management, selection widgets and tagging -- ranging from us having to 
load all resources on startup to present them in the selector widgets 
(which takes lots of memory) to the way notifying krita that a resource 
has been selected has grown over the years into something nobody really 
can comprehend anymore.


Boudewijn