Hi,
utils_strtod() has an **end output argument, like strtod(), but never uses it. Of course, all callers pass NULL, so it doesn't matter much, but it'll still be good to fix it.
Do you thing we shall handle the argument, or remove it? Assignind to *end doesn't make much sense, since on successful utils_strtod(), *end (if any) will always point to the end of the input string.
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().
Cheers Lex
On 2 December 2013 04:31, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Hi,
utils_strtod() has an **end output argument, like strtod(), but never uses it. Of course, all callers pass NULL, so it doesn't matter much, but it'll still be good to fix it.
Do you thing we shall handle the argument, or remove it? Assignind to *end doesn't make much sense, since on successful utils_strtod(), *end (if any) will always point to the end of the input string.
-- E-gards: Jimmy _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
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.
Cheers, Matthew Brush
On 2 December 2013 09:45, Matthew Brush mbrush@codebrainz.ca wrote:
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.
Untested, but looks ok, except it has changes not directly related to parsing colour like highlighting.c:698, s/b separate commit IMHO.
Cheers Lex
Cheers, Matthew Brush
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 13-12-01 04:34 PM, Lex Trotman wrote:
On 2 December 2013 09:45, Matthew Brush mbrush@codebrainz.ca wrote:
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.
Untested, but looks ok, except it has changes not directly related to parsing colour like highlighting.c:698, s/b separate commit IMHO.
That is using the new/re-written function, just like all the other changes.
Cheers, Matthew Brush
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
Le 02/12/2013 21:54, Colomban Wendling a écrit :
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.
Hum.
Le 02/12/2013 21:54, Colomban Wendling a écrit :
Le 02/12/2013 21:54, Colomban Wendling a écrit :
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.
Hum.
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.
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.
Regards, Colomban
On 13-12-02 06:16 PM, Colomban Wendling wrote:
Le 02/12/2013 21:54, Colomban Wendling a écrit :
Le 02/12/2013 21:54, Colomban Wendling a écrit :
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.
Hum.
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. 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).
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.
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 :)
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 :)
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 :)
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
On 5 December 2013 07:26, Tory Gaurnier tory.gaurnier@linuxmail.org wrote:
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.
And it doesn't understand Gamboge, a colour name that has been in use at least since the 1600s. #e49b0f :(
Cheers Lex
That looks like "pee yellow" to me...
On 12/04/2013 01:38 PM, Lex Trotman wrote:
On 5 December 2013 07:26, Tory Gaurnier <tory.gaurnier@linuxmail.org mailto:tory.gaurnier@linuxmail.org> wrote:
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.And it doesn't understand Gamboge, a colour name that has been in use at least since the 1600s. #e49b0f :(
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel