bb2a943350 Fix crash when the small color selector has zero size
4f47eca44e Cleanup some forgotten lines
05d5915a5a Remove pure virtual from KisColorSelectorComponent::setColor()
98f0a51d62 Add GPL2+ license to new files
4181901f1c PNG converter doesn't need half.h anymore
0347350087 Enable HDR mode in the autobuild script

The original patch was reversed. This is the correct one.

The patch looks and work okay here :)

In D18790#407680, @ashwind wrote:

actually the setdirty call wasnt working outside the lambda command. So i was a bit confused about calling it a from a higher level.

I'm sorry, but there are a few bugs in the patch:

The updated patch fixes the pixel grid problem. Though it breaks checkers rendering :(

I have pushed the fix with a minor change: setDirty() should always be called after the change has been done, not before that. Otherwise the patch was correct. Looks like I dropped the update part when refactoring this code to the strokes framework :)

The problem is fixed in d1cbe53f86d5a717321db9f4c61459af4e177722

The problem is this commit 5f02b6cf33b5bb87889d40e2bad4115f4575e357

Just to make it clear, when the unmultiplication code was initially written, there were no these artifacts on the transparent background. It is some regression in another place.

1. EXR images are not supposed to be viewed on transparent background. They are "light source"
2. With this patch we load it incorrectly anyways. See blue artifacts on the flame.

The patch restores the bug that this "unmultiplication" was fixing. To test the issue, CandleGlass.exr image should be viewed on black background.

The setDirty() call should happen somewhere at the higher level. I guess there was some code for it. I'll check later today.

I tried to fix the wrongly enabled actions in the arrange docker (when no shapes are selected). The bug appeared because of this patch:

Hm... the idea in interesting, though I still not sure if it is obvious to the painters that -/= and Ctrl++/- shortcuts work differently.

Congratulations! Your patch seem to work perfectly fine now! Please push :)

Here is a daft patch for activating Color Picker tool with a shortcut. You can integrate it and get rid of that global option. Then I'll finally test the feature for regressions and we will commit that :)

In D16833#389519, @emmetoneill wrote:

I've just pushed William's patch into master. The new mode can be configured globally in Krita settings (it is on by default).

That is not a problem either. As Deevad has shown in his video, the old effect
is still achievable.

I have checked the maths of the new algorithm. It looks logical and should work fine. I have also added a few comments to the code to make it easier to decrypt later. See patch snippet below.

I need to check the maths of it

I need to test this :)

In D18412#399923, @woltherav wrote:

Hm... I am not sure if it is wise to have this patch if it only changes the wraparound view but not the wraparound strokes.

1. BUG: Pixel Grid doesn't care about custom WA mode settings. It is painted in both directions whatever the settings are

Except double redo() of the command the patch looks kind of okay. I don't feel good about making the dialog non-modal, because it allows the user to open it multiple times. But the layer properties dialog is already affected by this bug, so it will not be too big regression.

Outch, I didn't intent to accept the patch. It needs fixes :(

The dialog after the patch seem to work. The only trouble I saw is some debugging output, it is seem to have been present before the patch. Can be removed though :)

The main thing that should be checked in such cases is the presence of deadlocks when trying to do some actions, when the dialog is open. E.g. opening this dialog again, or starting a filter, or changing the current layer or removing the current layer.

I have tested your patch. It looks like the rendering problem has gone, indeed. Though there are a few other smaller problems :(

Ah, if it is going to the the only ZIP provider, then it should be fine. Though we should check its Unicode support. I remember we had some troubles with people saving .kra images with Russian image names in it.

There is a problem inherited from the previous patch: copy-constructor and assignment operator do not copy the values for the precision. Therefore undo/redo will not work properly. Please add copying to ToolTransformArgs::init() function.

Here is the full tablet log for exactly two strokes. The first one with the normal "left" button, the next one with the overridden "Mouse 12 Button". It behaved exactly as in the video above. It dropped the stroke right after the start. From the log it looks like "Mouse Move" events do not have proper "buttons" field set. Therefore it recognizes teh button as being released.

There is some problem with rendering when using this patch:

I am okay with this very patch for adding the actions. They look okay and work fine.

The patch looks okay now. Though it lacks a necessary part: saving of the options to the config file. If you promise to finish the feature later, we can push it as it is (with the two stylistic changes I noted inline) :)

I still have a crash when trying to use your option. It looks like the config value gets uninitialized. I don't know how it happens, but it is not initialized :(
Here is the output:

When setting precision of the final result to '2', Krita crashes because of trying to allocate 0xffffffffffffffff bytes. I guess this precision level is not supported by the grid algorithm.

In T9256#173995, @troyjamessobotka wrote:

The scale is there to convert the conventional scaling of values to nits. That is, 0.18 would become 18 in ST.2084.

A patch for @troyjamessobotka's OCIO config for conform Windows convention:

In D17807#385686, @hellozee wrote:

Is there any other place where pixelPrecision value could be hardcoded? Cause if any value other than 16 is passed, it causes an assert.