Preset widgets refactoring
boud at valdyas.org
Mon Jul 13 11:35:37 UTC 2015
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
> 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
* 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
> 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 , 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 .
>  - https://community.kde.org/Krita/docs/Requirements_For_The_Resource_Management
>  - 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.
> Dmitry Kazakov
More information about the kimageshop