[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: The resource bundle and resource md5 sums.
From: Wolthera <griffinvalley () gmail ! com>
Date: 2015-01-23 11:53:49
Message-ID: CAN80MtF24uKtVFCUK+NxpS+0F9ejxKEJhNsVn6q5nUzkAWBfUg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
>
> 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
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_quote"><blockquote style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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.<br></blockquote><br></div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><br></div><div \
class="gmail_quote"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex" class="gmail_quote">2) Dirty bits. Sometimes it is \
quite difficult to ensure consistency of such bits. If we solve problem 1), can we \
avoid that?<br></blockquote>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.<br><br></div><blockquote style="margin:0px 0px \
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" \
class="gmail_quote">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.</blockquote><div \
class="gmail_extra">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.<br \
clear="all"></div><div class="gmail_extra"><br>-- <br><div \
class="gmail_signature">Wolthera</div> </div></div>
_______________________________________________
Krita mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic