<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Le 23/01/2015 12:00, Stefano Bonicatti
      a écrit :<br>
    </div>
    <blockquote
cite="mid:CAGMAV4_KFQPhdsFnJ_2Z-36kFuRT4R7GC_3US4NhDReTmF0U7w@mail.gmail.com"
      type="cite">
      <div dir="ltr">@Dmitry:
        <div>1) This is what i would say too, the problem though is that
          right now there are resources using XML that could be
          interpreted in different ways when on different PCs.</div>
        <div>Then there's also the problem of gradients files that when
          read the values in memory are different from the ones in the
          files and if with no modification you save the gradient again,
          you will obtain a file that is different from the first one
          even if it should be the same (you didn't do any modification
          so.. this is partially why detecting this modification would
          make sense).</div>
        <div>To conclude, if we keep resources how are handled now and
          choose to calculate MD5 on static (deterministic) data, there
          are parts of the non-static data that from one version to the
          other version changes, but maybe no static data changes, so
          you would have the same MD5 for two version that are actually
          different.</div>
        <div><br>
        </div>
        <div>2) Wolthera told me (and i still didn't checked) that there
          should be few places if not one where resources can be
          changed, so if changes comes from one source only, why it
          should be a problem?</div>
        <div><br>
        </div>
        <div>3) I don't think i completely get what you say here. Right
          now those "in memory only" resources can be saved as normal
          gradients in the bundles, so it does create a file from them
          with their correct names.</div>
        <div>The problem though is that if we have to calculate MD5 on
          files only (the real static data imho), they don't have it.</div>
        <div><br>
        </div>
        <div>@Boud:</div>
        <div>Well yes and no, UUID doesn't really guarantee that the
          resources aren't equal, it just works that it's statistically
          improbable that two different users can generate the same UUID
          for different resources, though since the UUID doesn't
          actually depend on the file, one can create two differents
          UUID for the same file, and this is bad :P.</div>
        <div>MD5 is the correct way, though here it's either calculated
          on the "wrong parts" or the resources are implemented in the
          "wrong way" (if one wants to guarantee to be able to recognize
          two equal resources by their content).</div>
        <div><br>
        </div>
        @Timothée:
        <div>But what if one doesn't want to overwrite the originals and
          want to prepare a set of bundles for others, or the like? (But
          it's not only that, please see point 1 of the answer to
          Dmitry).</div>
      </div>
      <br>
    </blockquote>
    In this case, saving new presets first and bundling them afterward
    makes more sense.<br>
    Without manually saving the preset, what name and thumbnail should
    the preset use? the same as the original one? So you end up having
    two preset with same name and thumbnail? sounds bad...<br>
    <br>
    <br>
    <br>
    <blockquote
cite="mid:CAGMAV4_KFQPhdsFnJ_2Z-36kFuRT4R7GC_3US4NhDReTmF0U7w@mail.gmail.com"
      type="cite">
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Krita mailing list
<a class="moz-txt-link-abbreviated" href="mailto:kimageshop@kde.org">kimageshop@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/kimageshop">https://mail.kde.org/mailman/listinfo/kimageshop</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>