Preset widgets refactoring

[Stefano Bonicatti]

I get what are you both saying but KisAcyclicSignalConnector, from what i
can see, is done to connect to base Qt signals, while i was more thinking
of using custom signals (as it is doing right now), which can send pointers
through signal. So if i have to use that i need to extend it.

Then though, boud: are you basically suggesting to rethink the whole
resource management?
Because i know the interaction requirements for the widgets and presets
(and well also the tag should be easy), but i don't know how all the rest
is done.
You might have to expand a bit what's your idea because for instance "ranging
from us having to load all resources on startup to present them in the
selector widgets (which takes lots of memory) ", do you mean that you think
about a widget that just shows name and icons for the preset but it
actually loads each preset on the fly when they are selected and then they
are kept in memory, forever or unloaded again when some number of loaded
preset is reached?
So like a "pool" but with fixed size.

i find it a bit difficult doing it just "on paper" without knowing all the
requirements and without seeing what the current code does, so that i know,
when i tear everything apart, what functionality i need to restore, plus
all the widgets that needs specific interaction/notices (as in
KisPaintOpBox).

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20150705/7aefa3ac/attachment.html>