The resource bundle and resource md5 sums.

Wolthera griffinvalley at gmail.com
Fri Jan 23 11:53:49 UTC 2015


>
> 1) MD5 must always be calculated on the static data. I don't know how we
> ended up to calculate it on derived/interpreted data, but it really sounds
> as a bug.
>

Well, to be fair what it does is calculate the md5sum on the
resource-object, and only when asked for it. This in itself is not a
problem. The problem is that Krita deforms the data from the data of the
original resource file, and thus outputs, say, different .ggr files than it
reads, because of precision issues. Similarly, tyyppi/Jouni commented on
something saying that the way brush-tips is loaded might result in a unique
md5sum per system.

2) Dirty bits. Sometimes it is quite difficult to ensure consistency of
> such bits. If we solve problem 1), can we avoid that?
>
I'll be honest and say here that I don't care much for it. Because
expecting users to save shit before moving it over to another computer
doesn't seem like such a far-fetched limitation to me. It's getting a
little in overengineering territory.

3) For only-memory resources like Bg/Fg gradients it might be enough to
> generate a default name for them and save real color values (current
> colors). I guess that is exactly what the user expects to do.

This as well is getting into overengineering territory. If we can accept
users having to deal with unusualy blending modes(to their feeling,
Blending modes are bugfree on the technical level) in LAB, why is it so
hard to have them understand that there's two gradients that they can't
chuck in a resource bundle, and they'll have to make them themselves? It's
not like foreground-to-background and foreground-to-transparent is so
complex.

-- 
Wolthera
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20150123/790950b6/attachment.html>


More information about the kimageshop mailing list