Le 01/12/2013 23:45, Matthew Brush a écrit :
On 13-12-01 01:26 PM, Lex Trotman wrote:
Hi,
**gint** utils_strtod()?? Sheesh.
s/b renamed utils_hexcolor() or similar, thats what it does.
As for "end", the original strtod() and friends used it to extract several whitespace separated strings from the one string by just passing "end" to the next call, but if we don't use it and its wrong anyways we might as well drop it when we change the name to utils_hexcolor().
Agree the name is bad, and also the colour parsing isn't very robust. I meant to improve it when adding the named_colors support but never got around to it.
Attached patch uses GDK colour parsing instead of own-rolled thing which supports more colour specification formats as well as cleans up some related code while remaining compatible with legacy colour notation and GTK2 and GTK3 builds.
If nobody objects, I can commit the patch.
As said on IRC, I don't want the color parsing to change depending on the GTK version Geany is built against.
Attached is a proposal using pango_color_parse() -- which is what gdk_color_parse() uses. It supports the 3 and 4-digit channels, even though we don't actually use such a precision, so it's a bit of a lie, but I guess nobody cares anyway.
This only renames utils_strtod(), make it stronger and port calling code, it doesn't include some of the cleanup you did like removing rotate_rgb().
BTW, I think it's probably better to write "0x0000ff" directly and add a small comment stating it's white rather than call a parsing function here, which looks odd.
Regards, Colomban