Preset widgets refactoring

[Boudewijn Rempt]

On Sat, 11 Jul 2015, Dmitry Kazakov wrote:

> Then though, boud: are you basically suggesting to rethink the whole resource management?

Yes. I just haven't had the stamina to write up a plan. I've been meaning 
for a week to asnwer Stefano's mail in more detail, but I haven't managed 
yet.

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

Well, I think even the selectors and tagging widgets interaction need a 
rethink before we can be sure it's worth spending the time on; there are a 
bunch of problems with the selectors we have now.

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

Right now, for some resources actually load, generate the icon, then 
discard the data until the resource is selected. (Or did I only do that in 
a branch which never got merged...).

What I want is:

* on startup, we read a database with name, filename and icon for all 
resources.
* on startup, we check whether there are new resources that are not in the 
database, then add those.
* on selecting a resource for the first time, we load the real data

Whether we try to keep memory consumption low by dropping resources in a 
sort of fifo isn't something I've thought about yet, but it could be a 
good idea.

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

In a default install - but artists will have way, way more resources than 
we package by default, which is one reason why photoshop uses the 
libraries concept. When you load a new pattern library, the other patterns 
are removed from memory.

Right now, krita cannot handle a situation where a user has collected 5000 
brush tips: it will cause a slowdown on startup, eat memory uselessly and 
the gui doesnt really support hanlding that many resources.

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

Sure, we're not at at stage where we can work on the code yet. And I might 
be out of context, but was this something you intended to work on now? I 
thought it started with the refactoring Smjert was thinking about.

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

Sure, but it'll take a bit of time and this time I really, really want to 
have a proper design for resource management. It's one of the oldest bits 
of Krita and has grown over the years through accretion.


> 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 :(

Very ugly. And it's been confusing me ever since that was split up, back 
when we did the Qt4 port.
> 
>  
>       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.

Yes, I totally agree with that. And that sometyhing we can ghet started on 
in any case, without looking at the whole resource management problem.

> 
> 
> Agree.
>  
> 
> --
> Dmitry Kazakov
> 
>