Comment 11 for bug 677081

Please find attached a better patch.

I've recoded the whole process. For me, the entry is just an input. When the user wants to modify it, he just not want that Inkscape modify it in the same time. Now what you type is what you want. It's no longer the color notebook that understand the RGB string but the color selector. This one takes an order (the color string) and try to update himself the best he can.

I've found no regression.

- The alpha will be kept but not appended as soon as the user don't want to change it (by typing it or move the alpha slider).
- The GtkEntry is now an Inkscape::UI::Widget::ColorEntry that is linked to a ColorSelector. This way we can reuse this widget anywhere we want.
- Now a SPColor can be created/setted with a RRGGBB string and ColorSelector accepts also this input for setColor.
- The entry will now keep the begining # when the user type it, I hope this will not be an issue as soon as lot of others IDE keep it and as soon as it will have no impact on the way Inkscape handles colors (and for future we should keep it to differenciate with names).

If this patch is accepted, two enhancements for the future that are not linked with this bug :
- We can propose other standards input formats (ie RGBA, RGB, color names, rgb(int, int, int)...), even if finally Inkscape convert them to RGBA hex values.
- It would be also possible for the parser to warn the user (by coloring the field in red?) that the entry cannot be used.

Enjoy :o) .