Inconsistent CMYK values in Fill&Stroke dialog

Regarding the bug: I found the piece of code that handles the CMYK values to be scaled as [0,1]. Now making a change to scale values in [0,1]-->[0,100] (though mentioned as a more industry friendly standard) shall require changes to generic codes which also handle the CMS sliders of RGB Color profiles. Also, the interconversions b/w floats of [0,1] to rounded of integers in [0,100] shall cause some loss of accuracy as well.

Can people who are more experienced in the designing fields be brought together for poll ? If many people want this change, I am up for tweaking the source file in question. Pardon my audacious attempt of suggesting an idea of taking a vote, but in my respect it does seem important.

PS: For the more experienced developers, am I right in thinking that the scaling will cause a loss of accuracy ?

Thankyou for the help.

Here is the patch for the required bug:

The scaled values appear in a GtkEntry beside the appropriate Spin Buttons. They are not drawn for color spaces other than CMYK. I suggest an improvement where scales can be accommodated (like they have been for CMYK in the patch ) for different Spaces as well. Shall work on it as soon as I get time.

Just a quick comment on the patch, please set your text editor to insert spaces rather than tabs when you press tab. It's just a coding style consistency thing throughout the code base.

Hi and thanks for the patch, unfortunately it doesn't quite compile on Linux :
1. itoa is a "non standard" function not available on Linux. Try using snprintf instead
2. gtk_entry_set_editable is obsolete/deprecated. Try using gtk_editable_set_editable instead

After testing things out, it appears this patch is heading a bit in the wrong direction.

Instead of adding a second edit field, it should just adjust the current one to have the proper range.

It also appears that the existing code is set up to have the range vary in additional ways, and there is some commented out code that should be close to what is needed for final.

I would just like to point out that the second field is not an 'edit' field. It just displays the correct scaled value according to the requirement.

@ScislaC: I shall do the needful. Thankyou for the information.

Modified patch on @john's recommendations.
This version is based on the latest trunk of Inskcape. The earlier version was incompatible with the current trunk due to late updations to my local branch. Sorry for the mixup.

Unfortunately, recent changes broke the patch attached comment #9 and it's no longer possible to apply it to the trunk. Could anyone take a look to the old patch and see if it's not too hard to update it?