<html><head></head><body>No offense, but a paint store isn't a very good comparison, because they have 100s of "named" colors, and you can get 1000s of mixes that then have their own names, when it comes to computer science we use RGB, we can't crack open a can of green and mix it with egg shells white, we use HEX or DEC values to mix red green and blue. And HEX is hardly cryptic, first two digits are red, middle two digits are green, and last two digits are blue. A program/API should always support HEX, and it's good practice to also support DEC values and named colors.<br><br><div class="gmail_quote">Colomban Wendling <lists.ban@herbesfolles.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Le 04/12/2013 03:31, Matthew Brush a écrit :<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">On 13-12-02 06:16 PM, Colomban Wendling wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">Le 02/12/2013 21:54, Colomban Wendling a écrit :<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">[...]</blockquote><br />Committed a different version that keeps our own parser, because as Lex<br />pointed out on IRC the named colors are weird, and as I mentioned 3 and<br />4-digit channels don't make much sense to us since this precision would<br />be lost anyway. And it's not that complex.</blockquote><br /><br />I missed the IRC conversation but IMO named colours are not weird[1],<br />actually it's quite readable to write "red" instead of some "cryptic"<br />hex intensity value.</blockquote><br />Yeah, right for simple names like "red", "green", "blue", etc, but<br />"light goldenrod yellow", "pale violet red 4", "grey 99"?<br /><br />And IME, people very seldom use named colors, because those generally<br />aren't the one they want. They don't want any kind of red, but the very<br />red they choose.<br /><br />Also, since you added those nice named colors, they can define pretty<br />names for the exact color they want and be happy :)<br /><br />And one thing I was partly afraid with supporting those default named<br />colors would be that people would make a typo in their named color and<br />bug us with "my color isn't my color". But that's probably<br />hypothetical, and users probably are smarter than that :)<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Even decimal RGB support is quite nice since most<br />people IME think in decimal and not hex, and most/all colour choosers<br />and related tools give the RGB values in decimal (although most give hex<br />values too).</blockquote><br />Most people think decimal no hex indeed, but most people also have no<br />idea how many red, green and blue make the pretty color they are<br />searching for. And as you say, most (if not all?) color picker provide<br />an HTML notation.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">IMO, even though it's fun to write a hand-made colour parser (which is<br />something I specifically avoided doing in my patch, kind of the whole<br />point of it actually :), we should still use the existing function<br />already used elsewhere in the code and linked into the binary anyway,<br />for the sake of avoiding duplicating code with our own not<br />widely-tested, debugged and less robust/featureful version.</blockquote><br />Using the same thing everywhere is indeed a very good argument. I have<br />nothing against using gdk_color_parse() everywhere then -- and fix<br />callers like tools.c's color picker not to do extra validation.<br /><br />I just committed a patch that does this, so now everything (should) use<br />the same code to convert string to colors. And since it had to be<br />compatible with gdk_color_parse() anyway, it uses it and supports all<br />it's feature set ;)<br /><br />So now everybody should be happy :)<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">That being said, I don't really care much, it's not a huge deal and as<br />you said the limited hand-rolled version isn't actually that complex.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><a href="https://github.com/geany/geany/commit/3522e81d7344c584a78c2f52cf8bcd32f14dd38d">https://github.com/geany/geany/commit/3522e81d7344c584a78c2f52cf8bcd32f14dd38d</a><br /><br /><br />@Matthew as said I only touched what was strictly related to<br />utils_strtod(), you may want to commit your additional cleanups.</blockquote><br /><br />I did it once already and you didn't base your changes on mine so you<br />can have the joy of repeating the effort if you would like :)</blockquote><br />OK, done.<br /><br />Cheers,<br />Colomban<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Cheers,<br />Matthew Brush<br /><br />[1]: Go to a paint store and see how many paint swatches have colour<br />names as opposed to hexadecimal notation printed on them :)</blockquote><br />That's an argument, but also in a paint store you chose the color that<br />looks like you want, not only its name :)<br /><hr /><br />Devel mailing list<br />Devel@lists.geany.org<br /><a href="https://lists.geany.org/cgi-bin/mailman/listinfo/devel">https://lists.geany.org/cgi-bin/mailman/listinfo/devel</a><br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>