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/3522e81d7344c584a78c2f52cf8bcd32f14dd38d
@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