Krita API - Active Color | PyQt5 - QSlider styling

[EyeOdin]

So I started working on a little color picker for myself because I kinda suck with colors.
Either way regardless of that I have 2 questions currently:

I made a UI and some code and it reacting for the most part inside PyQt5 but I still needs to make the changes to affect Krita itself.

I was looking around and if you want the change Krita’s color you need to use the “ManagedColor Class”? Is this right? I found like 5 classes that use colors but this one seemed the most promising for that.

Inside of it I only found a little piece of code example on how to actually use the class but it seems a bit…off to be usable from the get go.

The example:

import krita
import PyQt5

colorYellow = ManagedColor("RGBA", "U8", "")
QVector<float> yellowComponents = colorYellow.components()
yellowComponents[0] = 1.0
yellowComponents[1] = 1.0
yellowComponents[2] = 0
yellowComponents[3] = 1.0
colorYellow.setComponents(yellowComponents)
QColor yellow = colorYellow.colorForCanvas(canvas)

I Opened krita and the scripter and just pasted this in however it gives a error message and each time i try to edit I only make it cry even bigger errors so I stopped that

Is this a good example to start off on to change the active color? and what is it needed to actually work?

My Second question is about making a QSlider more responsive. I have searched style sheets for it and made them all pretty and stuff but the slider handle moves a bit clunky.

If you click on the handle and move it works fine but if you click on a empty spot on the slider you need to maintain the click for it to move to that point and it will not follow the mouse press after. While a color slider from “specific color selector” or “mixer color slider”(plugin) their sliders have a little white triangle and if you click on a empty area of the slider it instantly goes to that point and you can drag the handle around as if you had clicked it and dragged it.

I have read the mixer color slider python files and I can’t locate what is doing this effect happen.

I don’t want to make a triangle by obligation but if to have that click behavior you need it I would totally do it instead of the look I placed for the time being.

mine is looking a bit more like this now:

the HSL color square is wrong because I still have not implemented HSL only a RGB input into it yet.

Thank you for any help in advanced.

[Lynx3d]

I don’t know too much about the Python side of colors, but handling colors in the form of KoColor that krita uses internally is not that trivial, its internal representation is specific to the color model, channel depth and color profile it was defined in.
ManagedColor indeed seems to be the abstraction of KColor provided for Python.

However due to the complexity of this the Python docker you mention and even several of krita’s C++ color selectors only handle QColors which restricts them to sRGB. HSI/HSL/HSV are basically just alternative representations of RGB and hence require converting other color models (CMYK, Lab*, XYZ etc.) to RGB first anyway.

About the sliders, neither Mixer Slider nor Specific Color Selector use QSlider but implement them from scratch (inherit from QWidget only), that means they handle mouse events themselves, render the gradient and controls all by themselves.

See mixer_slider_docker/color_slider.py for the python plugin and libs/widgets/KoColorSlider.h/.cpp for the internal one.
Well actually the C++ ones are further encapsulated in KisIntegerColorInput and KisFloatColorInput to add the appropriate spinbox and percentage mode to it.

Maybe it would be a good idea to create Python bindings for those C++ classes…

[EyeOdin]

@Lynx3d

ManagedColor indeed seems to be the abstraction of KColor provided for Python.

I am going to try and focus on it then somehow.

@Lynx3d

QColors which restricts them to sRGB. HSI/HSL/HSV are basically just alternative representations of RGB and hence require converting other color models (CMYK, L a b*, XYZ etc.) to RGB first anyway.

Kinda sucks but I was aware of it already I was hoping python could handle the reall value correctly and then only transform to RGB and push to Krita after, but I doubt it would do anything better looking than RGB still.

@Lynx3d

About the sliders, neither Mixer Slider nor Specific Color Selector use QSlider but implement them from scratch (inherit from QWidget only), that means they handle mouse events themselves, render the gradient and controls all by themselves.

ooohh boi oh boi~~ okay that I was not expecting to be so, but it was done it is possible to do too I guess I need to study things with a different set of eyes.

@Lynx3d

Maybe it would be a good idea to create Python bindings for those C++ classes…

I am already overburden with tasks to do on my project and C++ is a even bigger detour, but I do need the tools I am trying to do. But I guess my only options really are to do like Mixer somehow or do it right by making new binddings in C++. I am still to hear much on the other binding on the paste thing that does not work yet (they must have not gotten to it yet) but if I did bindings perhaps I could correct it too I cant be banging my head on Krita forever I need to push blender and unreal more than 2d… I really need to ponder this well if there was some instructions on how to do bindings I would just follow that but the long route seems the only way available now, but I guess I already have gone this far too having 2 plugins blocked due to lack of bindings would be super frustrating to me :v

[EyeOdin]

I think I managed to place my little color picker to speak with Krita. the code sample I pasted, is like 2 in one. to call the “color from Krita” and “to apply it too Krita” really not very clear but I got it.

But regardless of that I seem to be getting a weird issue where only “Small Color Selector” goes bonkers with it and I still have not gotten around it for the time being and I doubt I will after the tests I made. Not sure if it is a bug but it seems to be lacking something compared to the other color selectors that are stable in comparison.

I have found some tutorials to make custom widgets and I am in the process to digest them in order to implement them. I did not know QPainter was so useful.

[Lynx3d]

The small color selector is the only one supporting HDR displays, so it has some special color space handling and even more special rendering code. Quite possible it’s simply a bug.

But without knowing in which way it “goes bonkers”, I can’t really tell you what the issue could be.

And yes, QPainter does a ton of things, especially since not only widgets but also QImage and QPixmap can be used as paint devices, so you can do a lot of fun things.

[EyeOdin]

On my color picker window I set up a event that detects your mouse “Leaving” and “Returnning” over it. This event triggers a “Krita check” that reads Krita’s current color value when it returns and then compares the color value with my color picker color value. If both values are different my color picker changes to Krita’s values…Seems pretty low processing and all that.

If I change the color value on ANY color picker besides “Small Color Selector” and then hover over mine to update it it will update just fine.

But if I change the color value with the small color selector and then hover over mine to update it will shift the Hue randomley by like into another primary or secondary color more than anything and sometimes changes the saturation and value. When I am lucky it will change back and forth to the right color.

@Lynx3d

The small color selector is the only one supporting HDR displays, so it has some special color space handling and even more special rendering code. Quite possible it’s simply a bug.

then this means it is probably working with a massive floatting point then, I will check if it is just that but i doubt it since I am the one doing the read.

[Lynx3d]

@EyeOdin

then this means it is probably working with a massive floatting point then, I will check if it is just that but i doubt it since I am the one doing the read.

Yes, at first glance it seems to output float RGBA independent of image channel type, but ManagedColor should convert to normalized float anyway. However, 8-bit/channel is not RGBA but BGRA internally I think, so there may be some quirks with channel re-ordering.

Foreground and background color are a bit tricky, basically their color space/profile is somewhat dynamic, depending on where it comes from. To be honest, I don’t know the policies either, if any exist at all.

[EyeOdin]

@Lynx3d

However, 8-bit/channel is not RGBA but BGRA internally I think

Yes that is true weirdley. I did it by hand the reoder in my code before I started using QColor that reorders that automaticley, it must be some alphabetical ordering or something inside it but should be restricted in the order going in for sure.

@Lynx3d

Foreground and background color are a bit tricky, basically their color space/profile is somewhat dynamic, depending on where it comes from. To be honest, I don’t know the policies either, if any exist at all.

I was trying to influence the Foreground color yes. it all depends which Color Selector you last used. that is what gives me this wierd behaviour. but I can’t say it is a “bug” “Bug”, because without my code that might be faulty all works well.

[EyeOdin]

well I managed to get the hang of the QPainter and I did some little sliders styling after.
I made diamond shapes and triangles, I perfer the diamonds but what do you like more?
I guess I can make other shapes too not sure what to do more though…

it reacts as it should and seems quite lighter since there is no ticks, but I am still not sure if that is a good or bad thing yet. Need to hook things up correctly though, values only flow in one direction still, but it is working.

[Mako_Matt]

diamonds are great