GitLab

Qt didn't properly pass down tablet events which caused problems with
hovering, TabletPress/Release.

BUG:423299
BUG:431611
CCBUG:429940

Horizontal wave controls now affect the wave that 'travels' left to right.
Vertical wave controls now affect the wave that 'travels' from top to bottom.

BUG:431665

The fix for QTBUG-87781 is to recreate an internal mapping in
QSortFilterProxyModel::setSourceModel(), and KisResourceModel calls
this in the constructor.
This leads to KisResourceModel::filterAcceptsRow() being called, which
ultimately fetches data via KisResourceQueryMapper::variantFromResourceQuery().
So the latter must not create a temporary KisResourceModel when processing the
data role used by filterAcceptsRow().

So only create the temporary model when actually required.

The problem happens begause the cancelled areas were not updated

Now this signal is emitted by the undo stack itself, there is no
need to emit that manually.

The patch consists of three different changes:

1) CancelSilentlyMarker is changed from a job to an atomic flag.
   Before this change, the job used to be cancelled before the
   actual flag was reset. It caused too many unnecessary updates
   to happen.

2) KisFilterStrokeStrategy now provides a cookie to show whether
   the procesing has finished or not.

3) This cookie is used in a new mode in KisSignalCompressor. This
   mode works as the normal FIRST_ACTIVE mode, with one exception:
   it has "the second" shorter timer that checks if the queue is
   already idle. If it is idle, then the signal will be passed
   before the normal deadline. This mode is activated by calling
   the second override of setDelay() that accepts isIdle callback
   for the state of the queue.

The modified state must be controlled by the undo stack. Therefore,
this signal is now emitted by KisUndoStore.

In cases where undo history is not implemented, like in compositions
docker, one should use KisImage::setModifiedWithoutUndo(). This method
marks image as modified until the next save operation. And this mark
cannot be overridden by the undo stack.

I've checked, the new code works correctly

The output files should be written into the same directory,
where the unuttest binary resides. On Windows this directory
is not the same as ${CMAKE_CURRENT_BINARY_DIR} because of
linking complications.

The patch also removes the usage of EXECUTABLE_OUTPUT_PATH,
which is deprecated and not used anymore.

(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.