Preset widgets refactoring

[Dmitry Kazakov]

On Sun, Jul 5, 2015 at 12:07 PM, 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.
>

Well, I have nothing against extending it :) Though, yes, i twould be
better to keep the class as general as possible.


> 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 think we don't need to limit loaded resources. If loaded, it can be kept
in memory forever. We just need to avoid loading everything at once on
start. Right now, all the loaded resources take about 100MiB right on start
of Krita, even when no image is open.


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

How about collecting all the requirements in one place? I have just created
a page on the wiki [0], let's use it for all the requirements we could
think of.

There is also a page that Ilya Portnov from the Russian Community created
with the wishes for the presets infrastructure [1].

[0] -
https://community.kde.org/Krita/docs/Requirements_For_The_Resource_Management
[1] - https://community.kde.org/Krita/docs/Krita_Presets_Wishes

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

Yes, I'm totally agree with you. And what is more,
KisCanvasResourceProvider resulted in being just a convenience wrapper
around KoResourceManager, resulting in two different ways of accessing
resources, which is a bit ugly :(



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

Agree.


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20150711/92a25d3a/attachment.html>