Preset widgets refactoring

[Boudewijn Rempt]

On Sun, 5 Jul 2015, Stefano Bonicatti wrote:

> And about the central class, KisCanvasResourceProvider, yes it's central but it's not exactly what i had in mind
> (well nothing says that the way i was thinking is the way to go, but want to explain where i see a difference from
> what i was saying and what you both said): the provider right now is pretty dumb, more than a manager that decides
> things, is just something that does what other tell it to do.
> It just stores resources and then emit the canvasResourceChanged signal to inform others that something has
> changed.
> Currently it's KisPaintOpBox that actually behaves like the class i was thinking about (its setCurrentPaintOp does
> a lot of work and "decisions"), except that it's a widget which imho shouldn't do all that work.

I see what you mean, and yes, that's a pretty good point. Maybe a good 
refactoring start would be to tear KisPaintOpBox in two classes?

> So i'm not obviously saying that KisCanvasResourceProvider has to be reworked, especially since it's used by
> several other classes, but we need to move the logic from the widgets and especially from KisPaintOpBox in another
> class, then yes the provider can be the reference for that class, for the current paintop preset instead of having
> a personal management of that.

Ah, yes, I think that's the right approach :-)

Boudewijn