GitLab

(cherry picked from commit 7f4f7504a446af75e072ea283b149b9dcd693e27)

mypaint doesn't expose json-c in its API so having this PUBLIC (the
default) is unnecessary and above all causes linkage problems.

The problem was in the fast-path branch which used wrong pixel type

Many thanks to Mathias Wein for tracking down this problem:
graphics/krita@76c28d6a

BUG:404133

Basically, when the user changes visibility to and fro, the undo step
should be removed.

CCBUG:389876

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.

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.

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.

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.

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.

Before this commit, New wouldn't work at all. This commit fixes it
for the case when there is no CustomStyles.asl storage yet.
If the CustomStyles.asl storage already exists, nothing happens.

Before this commit, Folder Iterator would crash on files
that don't have a proper loader. Since we never know what files
users can have, and the FolderStorage doesn't check for correctness,
let's not assert here.
This commit changes Q_ASSERT to warnKrita and returning false.

This happened to me on layerstyles/..._style file, which
doesn't have any mimetype nor any loader, because it was empty file,
because it was a failed attempt at saving an ephemeral resource.
However from my understanding of the code, it can happen for other
invalid resources, so still, let's not assert.

And add a hidden option to enable the thumbnails: they really are
too slow to be of use.

(cherry picked from commit 5d05dcd808d57aa0409b022831c89086394140cf)

Create an action for the tool in the toolfactory's createActions
method, so it's already present when the factory is created, not
only when the tool is created.

They still don't get created in time for adding to the toolbar
on startup, but now they have icons. Plus, references to tools
that have been removed have been removed.

(cherry picked from commit 378afe5b1af7ac55e96c08e30eb7945f209c59c1)

Now KisDocument has a special field imageModifiedWithoutUndo, which
records the fact if modifying the image without undo, e.g. by changing
layer visibility. This field ca be reset only by saving the image,
not by changing the state if the undo stack.

BUG:389876

It triggers while autosaving, which is not what we really want.

(this patch is NOT portable to 4.4.2)

(this patch is portable to 4.4.2)

Should help make dragging feel more responsive when trying to drag a range of
frames to a new time.

Note: Accessing the channel via paintDevice is probably improper long
term, but fixing the crash should be good enough for now.