Comment 15 for bug 166622

@Carey Underwood: As you may know or not, CMYK numbers don't mean a thing unless they are related to a CMYK profile. That's why Jon Cruz suggested you to use one.
If you already know the risks of not using color management and just want a "close enough" approximation the CMYK tab is your friend.

(I won't get into much detail about color management, I don't want to sound like an ass about it. If you feel I should get into more detail, let me know.)

However, I see your point. Values shift while writing them in each box which makes impossible to input some values verbatim. But I would say this is normal. What inkscape does is taking the common components of CMY and placing some "ink" on K. So when you have any value >0 on all three CMY spinboxes, the value on K and the rest of the spinboxes will change. But the resulting color seems rather logical.

For instance, you have 0/30/30/0, and then go to the C spinbox and input 30.
* What you would expect is this: 30/30/30/0
* What you get is this: 1/0/1/30
That's because CMY 30/30/30 is a neutral color[*] (i.e.: gray) so inkscape decides using K=30 and lowering CMY to 0 (or almost), since that's an equivalent neutral color.

So when you write c:81 m:18 y:34 k:0 the values shift because inkscape takes into consideration the three >0 values and looks for an equivalent color using K too.
In other words, even though values shift you're getting the "right" color (as right as it can which an unmanaged system like this).

[*] With real inks this equivalence is not right, C usually has to be higher than the rest to get a neutral color.