The text looks very nice, detailed and precise! :) I don't see any problems in it. If we find any problems/inconsistencies, we can always adjust it on the fly :)

Perhaps, you could highlight the eye icon somehow, when there is something in stasis? Or gray-out all hidden layers? Because right now the behavior looks really crazy. I couldn't understand how it works before I read the explanation at least three times.

Well, I couldn't reproduce the problem before the patch. And neither I could reproduce it after the patch. At least it doesn't do any regressions :)

The patch works perfectly fine now and does exactly what is declared! Please push! :)

I think a separate dialog for selecting would be the most convenient for the users. And @vanyossi's idea about merging this dialog with the layer properties is very good. Actually, properties dialog is the most obvious place for the users to search for this option. Though it might be not very easy to add switchable options to it. I guess we could add a pager-widget to it and add pages for custom options like for clone layers and file layers. Though it will be quite a bit of work.

The patch works perfectly fine! Please push! :)

The patch looks perfectly fine, please push! :)

I can confirm, Windows Pointer API doesn't support more than one (right) button. Just by-design. Theoretically, drivers might try to add a hack to report more (and breaking the protocol), but none of the drivers I tested do that. So I'm not sure what we can discuss here :)

Could you please test the very latest nightly build with WinTab setting? I've implemented auto-update of the desktop resolution. It should kind of work now.

The patch doesn't build here. But I have a feeling that changing key colro in color-to-alpha from white to grey will do what you want.

Ooooooh... we have a feature like that. I guess we still have leftovers of it in KisBaseNode::Property::stateInStasis. The feature never worked as expected by the users and gave us a lot of pain. E.g.

Just for reference:

@razvanr! I'm sorry that we seem to forget about this patch. I asked painters' opinion on that, so we should get feedback soonish.

Here is a version of this patch rebased against the current master (with PNG files fixed): d228719365f789045fc7ba01b4db4acd91b1d0f5

Please check the inlined comments. It might also be nice to name the files according top the new naming convention, like HighPassFilter.cpp (without Kis prefix and in BigCamelCase).

The patch seem to fix the original problem, but it introduces a crash (with ASAN enabled). When you switch to gradient fill/stroke and the shape doesn't have gradient yet, it crashes with invalid memory access:

The patch works fine now! Please push! :)

Just an idea:

As far as I can see, this patch just hardcodes functionality of Color to Alpha filter with white color selected as a reference. Why do we need this as a separate filter?

Speaking truly, I don't understand, what bug this huge refactoring is intended to fix. Please list the problems you are trying to resolve.

The patch looks fine, please push!

The patch looks fine, though there are two issues. See the attached video to see illustration of these issues:

The patch looks fine. Please update the comment I noted inline and push

If you have any problems with building the test, please just try to update to 1.4.1 and try to paint on 8-bit image and on 32-bit-float image. If both types of painting work, then it should be fine to use it

The patch looks and works fine, please push! :)

Is it possible to run KisCompositionBenchmark on your system? (it is commented out in the build system atm). If it runs the same on both versions, I guess it should be okay just to update the version of Vc on OSX

In D18792#442355, @scottpetrovic wrote:

Where my changes start overlapping with @gdquest's idea is it has to do with layer changing.

Here is video illustration:

For point 1 and "finishing" the transform. This might need some discussion with artists. We might need to change our definition of what "finishing" a transform means. I think some people are not expecting the transform tool to finish until they move to another tool. I didn't even think about this until I saw a @gdquest video on how he is switching layers and doing multiple transform while staying in the transform tool. Right now he has to click on the canvas again to "re-activate" the transform handles...which for him is a limitation. Here is the video at the time... https://youtu.be/33Hym2srxpo?t=238

Now there are two severe regressions :(

The patch seems to work! I don't know we didn't use it before. perhaps it was not present in older versions of Qt :)

The patch works fine, please push it without further review :)

There are two very small issues still:

In D18792#440201, @scottpetrovic wrote:

Just a note about that "work recursive" toggle on the tool options for the transform tool.

That property seems to be forcing its value on and off with every start stroke...which is making using it kind of confusing.

if (m_optionsWidget) {
    m_workRecursively = m_optionsWidget->workRecursively() ||
        !currentNode->paintDevice();
}

I am not sure why this logic is there in the startStroke(), but maybe there is a better way to manage the state of that bool

From a quick glance, it seems like point 2 is not fixed yet:

Should this 3rdparty dependency be available only on OSX? Or it is intended to be built on all the platforms?

The patch has a lot of commented out code and doesn't do what it is intended to do: the widget is not scaled: