Also, I guess because of this the color spectrum is also different which can result in bigger problems when you want to use harmony colors.

I think is normal that the inputs from nodes to be the same no matter what Color managements you may use.
Or at least to have an option to choose.

Regard to this, also if you make a print-screen the RGB color in Blender and put in Photoshop or Gimp and make Eyedropper to the color, will be a different color from Blender.

All the colors are wrong, the codes, the colors spectrum, inputs, outputs, render. it's crazy.....

I suppose this is another bug, or a bad design haha

It's the trade-off you make for physically based rendering, things are more complicated and you can't just use print-screen and expect things to match.

In T60582#601282, @pistol ioan (pistoltoto) wrote:

I suppose this is another bug, or a bad design haha

This is a design conundrum; should the various UI colour swatches factor in the colour management view transforms and exposure setting, or instead use a normalised range? Currently they do the latter.

But, the eyedropper and viewport *do* take into account exposure/view transforms, so there's a discontinuity there.

On a separate issue; there isn't a colour management configuration that avoids the colours slowly drifting if you keep eye-drop an object's own geometry in the 3d viewport - so I don't know what colour space the swatches and viewport are operating in - (it doesn't look to be sRGB primaries / EOTF.)

Tested with both Cycles in 2.79 and Eevee in 2.80.

This last part potentially looks like a bug.

Actually, those color boxes only look different in regards to what it's selected in the "Display device" setting, not the view-transform, which causes no changes on the appearance of the color box.
So in the only sense that those boxes are "managed" is that they are tied to the "sRGB" field in the Display Device setting, but nothing else.
So yes, if you change that setting to any other option available (like None in the captures from this report) they look something else instead of sRGB-like, but that is it. View-transform isn't in the chain there, regrettably. All color related fields in Blender's UI should at least have a checkbox to go through the pipe of all transforms in the color-management panel.

I remember discovering that when evaluating the fact that the RGB values for those colors are linear, but the HSV values are sRGB. But if you change the Display device to "None" in 2.79, they are both linear. Unfortunately, this got further broken in 2.8, where HSV is now truly hard-coded to sRGB, and this -however convoluted- workaround to set linear values in HSV mode doesn't work anymore.

The eye-droppers are a different discussion, right now they are pretty much useless for anything beyond what you would get from picking colors from a screen-capture of itself.

In T60582#620115, @Joaquín Kierbel (Jk) wrote:

Actually, those color boxes only look different in regards to what it's selected in the "Display device" setting

Yep, although I hesitated to say the UI colours are tied to the display device setting since they look slightly skewed;

an emission shader of (1.0, 0.0, 0.0) with the default sRGB display device and sRGB EOTF doesn't give an 8 bit (255, 0, 0) value to the screen - its (248, 1, 1) - which seems more than just a rounding error.

EDIT: Ignore the above. It looks like my troubles are from a non-standard OCIO config file.