Preset widgets refactoring

[Sven Langkamp]

On Sun, Jul 5, 2015 at 11:07 AM, Stefano Bonicatti <smjert at gmail.com> wrote:

> 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.
>

The requirements are evolving all the time. Originally the preset could not
be selected at all and would just write the setting in the brush setting.
Then presets could be selected. Then we added another docker, another
strip, favorite presets and resource bundle manager and tagging system.
There are some widgets that have to be synced and some that don't.

In any case you will at some place have some code that has to prevent
cyclic updates just due to the way Qt handles table views. At some point
you have decided on a case by case base if a certain widget is synced to
the globally selected preset e.g. if you have some sort manager where you
don't want.

KisCanvasResourceProvider is the class that in the central managing the
resources so the preset should be coordinated there, maybe make a sub
manager class there. I would keep the KoResourceItemChooser as it is.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20150705/f1892603/attachment.html>