GitLab

BUG:430125
BUG:430181

It looks bugged, because smudge brushes will copy the smudge from the other
side of the image, but this is exactly how MyPaint handles it as well, so...

We still need to composite them on a precise paintdevice, and also handle
mirrored dabs...

This was especially visible with the colorize mode.

Tibor Nagy authored Dec 03, 2020 and Dmitry Kazakov committed Dec 07, 2020

Let them pass through to the canvas itself.

Peter Eszlari authored Dec 04, 2020 and Halla Rempt committed Dec 07, 2020

also replace deprecated XDG_APPS_INSTALL_DIR with KDE_INSTALL_APPDIR

Rebecca Breu authored Dec 04, 2020 and Halla Rempt committed Dec 07, 2020

Add a new action to the Tools -> Scripts menu: "Import Python Plugin
from Web"

This lets you paste a URL from which to download and import the
plugin. The URL can either be a link to a Github repository, in which
case the plugin will automaticallly determine the zip download
location, or it can be a direct link to a zip file on any website.

The existing plugin import action has been renamed to "Import Python
Plugin from File"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

Fetching resources from unittests now needs some special kind
of initialization. Instead we can just create a fake pattern.

We should make the process of initialization for
StoryboardItem more fool-proof. Now it just crashes
with invalid memory access when some of its fields are
not properly initialized.

The preset's update signals are compressed, therefore we should
wait for them.

Sharaf Zaman authored Oct 14, 2020 and Dmitry Kazakov committed Dec 04, 2020

for reversed: image had an extra 1px on right and
bottom which isn't right.

BUG:429165

It runs fine locally, but fails on jenkins. Perhaps because different
blending algorithms are used.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

We used to have freehand selection tool, which was gone after
we allowed normal painting on selection masks using overlay.

BUG:425894

1) Add a checkbox for hiding bezier control points. Several independent
   painters said they don't need them.

2) Add two spinboxes for reshaping the mesh

# Conflicts:
#	plugins/tools/tool_transform2/tool_transform_args.cc
#	plugins/tools/tool_transform2/tool_transform_args.h

The patch bascially makes symmetric transforms be the default choice
available without any modifiers.

Now the shortcuts are the following:

1) Mesh node:
   - click+drag --- move node

2) Border node:
   - click+drag --- move node
   - shift+click+drag --- move whole row/column
   - ctrl+alt+click+drag --- split/slide row/column
   - ctrl+alt+click+drag-away --- remove split

3) Control point:
   - click+drag --- change control point symmetrically
   - shift+click+drag --- change control point non-symmetrically;
                          this action will create angular texture
                          artifacts
4) Node or Control:
   - ctrl+click --- select multiple nodes

5) Patch area:
   - click+drag --- free patch deform
   - shift+click+drag --- move whole mesh

6) Empty area outside mesh:
   - click+drag --- rotate mesh or selection
   - ctrl+click+drag --- scale mesh or selection
   - shift+click+drag --- move mesh or selection

CC:kimageshop@kde.org

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

Before this commit, one offset would move the crosses between lines
upwards (even though the offset was in positive direction),
and the other offset would move it upwards-right (diagonally).
This commit moves them this way: if it's X offset, it moves the crosses
to the right (just like the rectangular grid does), and if it's Y
offset, it moves the crosses downwards (like the rectangular grid).

It makes it more user-friendly since it brings consistency with the
rectangular grid and more sense to the X/Y descriptions of the offset.

Before this commit, the isometric grid would start from both
the top left and top right corners, but those lines would actually go
upwards, so for the user, it would just look like random offsets.
This commit moves the lines topleft/bottomright with such offset
that it would start exactly in the (0,0) top-left corner, which makes
the grid much more understandable for users and it lets it be always the
same when user extends or shrinks the canvas starting from top-left
corner (which is consistent with the rectangular grid).

This commit changes the offset of isometric grid with the same
settings, so it might break user files. However before recent changes,
the isometric grid would be always incorrect in case the user
zooms in the image (when the updateArea doesn't fit the whole canvas)
so it's better to do those changes now than later.

There is no snapping with isometric grid. The offsets moves the grid
exactly as they did before my changes.

Before this commit, KisToolSelectSimilar would use oldRawData()
instead of rawDataConst(). Because there was no transation on the
paint device, the result was exactly the same, however it is still
more appropriate to use rawDataConst() there instead.
This commit shouldn't change the behaviour of KisToolSelectSimilar.

Before this commit, every time a user would open a new image,
the Similar Color Selection Tool would reset to the Current Layer
option. This commit remembers user's decision regarding the mode.
Note: the color labels are not remembered, because they depend
on the image. It could probably be remembered and restored in some
smart way, but it's not done yet.

Before this commit, in some cases selection would be very uneven
and unexpected by the user.

Test case:
- transparent layer
- brush: Basic-5 Size
- color: green (anything very different from black will do)
- paint a dot
- Fuzziness: 1
- mode: Current Layer

That was caused by the fact that some pixels would be painted
with green and have opacity = 0. In case of Fuziness = 1,
the whole color is checked using memcmp method.
For transparent pixels it doesn't matter which color they are painted
with, it's enough that they are all transparent (for the user and for
Krita all fully transparent pixels are treated the same way, as having
one and the same color).
Hence this commit adds a check for just opacity in case of transparent
pixel.

Before this commit, the similar color selection tool would calculate
the selection based only on the paint device content, ignoring the image
bounds. This commit ensures that imageRect is always included for
calculations.

Note that the imageRect still won't be selected if the pixels are of
different color. It only affects the case when for example the user
clicks on a transparent pixel and the non-transparent pixels on that
layer are only located on the top of the layer; assuming that
defaultPixel color is black-transparent, as usual for new layers,
the selection search area will be extended to cover the whole image
to allow for selection to cover the lower parts where all pixeols are
transparnet, but are outside of the paint device bounds.

Before this commit, KisToolSelectSimilar in Color Labeled Layers
mode would only select areas inside image bounds.
This commit allows it to select areas outside of image bounds as well.
It divides the areas outside of image bounds into four parts
and calculates every part in separate command, which allows
better multithreading.