Gobber/libkis channel setvisible
Fix for Bug 432226: "Calling setVisible() on a node's color channels does not behave as expected"
In the original 4.4.2 code, the setVisible() method in libs/libKis/Channel.cpp attempts to retrieve the current active status of each channel, and modify only the specific channel's visiblity.
It uses the following code to retrieve the active status for all channels:
QBitArray flags = d->node->colorSpace()->channelFlags(true, true);
This looks to be a mistake though - what this code does is return the kind of each channel, ie. whether it is a color channel or an alpha channel, for the colorspace of the node.
The end result is that the current active status of all other channels are overwritten (set to active), and only the requested channel's active status is correctly overwritten.
I believe the code needs to call
QBitArray flags = layer->channelFlags();
since it later on updates the channels using
layer->setChannelFlags(flags);
This can also be seen in the Channel::visible() method, which uses this call to retrieve the active status.
Test Plan
-
Start Krita
-
Create a new blank document
-
Open the Tools->Scripts->Scripter
-
Run the following script in the scripter:
from krita import * activeView = Krita.instance().activeWindow().activeView() activeDocument = activeView.document() activeNode = activeDocument.activeNode() for i in range(4): activeNode.channels()[i].setVisible(False)
-
Open the layer's properties dialog
-
Observe the active channel status
All channels should now be inactive.
In the current 4.4.2 build, only the last channel will be active.
I have not run any relevant unit tests - this is my first time modifying Krita (or any KDE program for that matter), and I'm not sure how to go about this. Any help would be appreciated.
Formalities Checklist
-
I confirmed this builds. -
I confirmed Krita ran and the relevant functions work. -
I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!) -
I made sure my commits build individually and have good descriptions as per KDE guidelines. -
I made sure my code conforms to the standards set in the HACKING file. -
I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.