1. 19 Jan, 2021 4 commits
  2. 18 Jan, 2021 5 commits
  3. 17 Jan, 2021 1 commit
  4. 16 Jan, 2021 1 commit
  5. 15 Jan, 2021 8 commits
  6. 14 Jan, 2021 5 commits
  7. 13 Jan, 2021 11 commits
  8. 12 Jan, 2021 5 commits
    • Agata Cacko's avatar
      Comment out the "Could not find..." debug again · 6ece3f60
      Agata Cacko authored
      Before this commit, the qWarning() "Could not find resource in the
      database" warning was not commented out. That results in lots of
      debug code that sounds scary but it actually happens on every resource
      that is found in the local resources folder but not in the database
      - which means for example on creating the database from scratch.
      This commit comments it out again and adds a little comment
      explaining why it's commented out.
      6ece3f60
    • Agata Cacko's avatar
      Add layer styles using "New..." when CustomStyles.asl exists · 3728d0bb
      Agata Cacko authored
      Before this commit, it wasn't possible to add new layer styles
      when CustomStyles.asl already existed. This commit fixes that
      by adding a new function to KisAslStorage and implementing
      adding to the storage in the dlg_layer_style.
      3728d0bb
    • Agata Cacko's avatar
      Don't add versions of resource already present in the database · 47b688fd
      Agata Cacko authored
      Problem: (copied from the commit with the title:
      "Don't add inactive versions of resources as new resources"
      (I cannot say the git hash because it's only local here
      for now, so it would be incorrect anyway)
      
      ---
      KisResourceCacheDb, noticing the resource already
      exists, checks for timestamp and adds a new version if needed.
      However at this point it *shouldn't* be needed, ever, no matter what
      timestamps say.
      
      If a filepath is in the database, then it means Krita knows about it
      and already has this filepath remembered. Adding a new version with
      the same filepath doesn't sound reasonable. If the user replaced one
      resource with the same, called the same way, it means we might need
      to update the thumbnail and/or the name, but adding anything to the
      database - no, because there is no *more* resources, they were
      *replaced*.
      
      With proper versioning and the feature "revert to previous version",
      it will lead to even more trouble, with the newest-by-timestamp
      version replacing the user-selected current version on every restart.
      ---
      
      This resulted in multiple versions with -1 number and generally
      duplication of versions.
      
      Instead, we should just update the timestamp. (Also why would we use
      timestamp now, anyway?) Note: this commit doesn't do that yet.
      47b688fd
    • Agata Cacko's avatar
      Rename the preset instead of creating a copy · cf8d010a
      Agata Cacko authored
      Before this commit, Krita would try to make a copy of the preset
      with a new name and remove the older one. This commit uses the
      KisResourceModel::renameResource() function instead,
      which results in a renaming happening only in the database.
      
      Note: because the resource is not valid after apparent changes,
      renaming the resource still doesn't work (it returns from the
      function early). However that should ensure no crashes.
      cf8d010a
    • Agata Cacko's avatar
      Don't add inactive versions of resources as new resources · 02186b34
      Agata Cacko authored
      Before this commit, if you changes the palette, it would all work
      fine (all changes would result in a new version of the palette,
      not a whole new resource), but after restart all the other versions
      of the palette would reappear in the palette docker. That was caused
      by the fact that ResourceCacheDb never checked whether the resource
      is already a version of another resource when synchronizing database.
      
      This commit fixes it by ensuring that 'resourceIdForResource' finds
      the resource id of the current version of the resource even for the
      resources that are marked as old versions of the resource (so they are
      not present in the `resources` table but only in `versioned_resources`.
      
      Possible problem: KisResourceCacheDb, noticing the resource already
      exists, checks for timestamp and adds a new version if needed.
      However at this point it *shouldn't* be needed, ever, no matter what
      timestamps say.
      If a filepath is in the database, then it means Krita knows about it
      and already has this filepath remembered. Adding a new version with
      the same filepath doesn't sound reasonable. If the user replaced one
      resource with the same, called the same way, it means we might need
      to update the thumbnail and/or the name, but adding anything to the
      database - no, because there is no *more* resources, they were
      *replaced*.
      With proper versioning and the feature "revert to previous version",
      it will lead to even more trouble, with the newest-by-timestamp
      version replacing the user-selected current version on every restart.
      02186b34