Krita Colorspace and profiles

Stefano Bonicatti smjert at gmail.com
Fri Mar 25 11:02:30 UTC 2016


> Of course, but that's some general point that you could make about
everything.

That's not so general. The point is and should always be to produce a code
that doesn't leave much to wonder about possible issues and to restrict the
possible errors done by the user.
Sometimes that can be done by actually simplifying code, sometimes more
checks have to be added, but the code should remain, as far as possible,
clear.

Now not on all code we have to apply this (that's why i'm saying it's not
that general), and i'm actually pointing a finger to specific code, as i
did for the preset widgets.
So all in all my point is that "it worked till now, no bug don't fix it"
imho is definitely not the right mindset given the speed of which Krita
increases its dimension.


> Okay, that is a problem. But we need to be really careful when touching
this code [...]

Rereading myself i might have explained this "wrongly", meaning that, it is
possible to "cleanly" delete the resources, but imho, doesn't make sense:
the factories would have to be deleted as the first thing in the registry
constructor and they would have to remove from the registry, through a
call, all their cached colorspaces that aren't owned by the registry itself
(checking the flag).
Only then the registry can loop through the remaining colorspaces, flag
them to be deleted and actually delete them.
I don't know, this doesn't seem straightforward to me, and i don't see any
reasons to do it. A better course would be having the registry own
everything and the factories just build what they are supposed to, without
holding anything, and then when having to release, the registry release
everything.


> [...] it's not a mess because we're too stupid to do it right: it's grown
into a tangle because it contains years of bug fixes.

I don't think you're stupid, i just think that when i see a tangle, i want
to disentagle that as a first thing, before anything else, before stuff
gets built on it that then needs to be changed as well, complicating a lot
more the task.
Those issues together with other are all very dangerous time bombs.

That been said, i still didn't understand if it's correct that color
profiles can be created and added to the colorspace registry *after* the
startup or not (because this is happening now already).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20160325/7f6aa627/attachment.html>


More information about the kimageshop mailing list