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.
Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 04/12/2013 03:31, Matthew Brush a écrit :
On 13-12-02 06:16 PM, Colomban Wendling wrote:
Le 02/12/2013 21:54, Colomban Wendling a écrit :
[...]
Committed a different version that keeps our own parser, because as
Lex
pointed out on IRC the named colors are weird, and as I mentioned 3
and
4-digit channels don't make much sense to us since this precision
would
be lost anyway. And it's not that complex.
I missed the IRC conversation but IMO named colours are not weird[1], actually it's quite readable to write "red" instead of some "cryptic" hex intensity value.
Yeah, right for simple names like "red", "green", "blue", etc, but "light goldenrod yellow", "pale violet red 4", "grey 99"?
And IME, people very seldom use named colors, because those generally aren't the one they want. They don't want any kind of red, but the very red they choose.
Also, since you added those nice named colors, they can define pretty names for the exact color they want and be happy :)
And one thing I was partly afraid with supporting those default named colors would be that people would make a typo in their named color and bug us with "my color isn't my color". But that's probably hypothetical, and users probably are smarter than that :)
Even decimal RGB support is quite nice since most people IME think in decimal and not hex, and most/all colour choosers and related tools give the RGB values in decimal (although most give
hex
values too).
Most people think decimal no hex indeed, but most people also have no idea how many red, green and blue make the pretty color they are searching for. And as you say, most (if not all?) color picker provide an HTML notation.
IMO, even though it's fun to write a hand-made colour parser (which
is
something I specifically avoided doing in my patch, kind of the whole point of it actually :), we should still use the existing function already used elsewhere in the code and linked into the binary anyway, for the sake of avoiding duplicating code with our own not widely-tested, debugged and less robust/featureful version.
Using the same thing everywhere is indeed a very good argument. I have nothing against using gdk_color_parse() everywhere then -- and fix callers like tools.c's color picker not to do extra validation.
I just committed a patch that does this, so now everything (should) use the same code to convert string to colors. And since it had to be compatible with gdk_color_parse() anyway, it uses it and supports all it's feature set ;)
So now everybody should be happy :)
That being said, I don't really care much, it's not a huge deal and
as
you said the limited hand-rolled version isn't actually that complex.
https://github.com/geany/geany/commit/3522e81d7344c584a78c2f52cf8bcd32f14dd3...
@Matthew as said I only touched what was strictly related to utils_strtod(), you may want to commit your additional cleanups.
I did it once already and you didn't base your changes on mine so you can have the joy of repeating the effort if you would like :)
OK, done.
Cheers, Colomban
Cheers, Matthew Brush
[1]: Go to a paint store and see how many paint swatches have colour names as opposed to hexadecimal notation printed on them :)
That's an argument, but also in a paint store you chose the color that looks like you want, not only its name :) _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel