Git master, Linux, GTK+2 and GTK+3.
1. Select *Tools* → *Color Chooser*. 2. Pick some color. 3. Click *OK* (GTK+2) or *Select* (GTK+3).
Expected result: Geany inserts the color that I picked.
Actual result: sometimes (randomly, in about half of the cases) Geany insert a slightly different color. For example, if I pick #655252, it might insert #655252 or #655151.
I didn’t have this problem on Geany 1.27.
Can't reproduce with Geany git and GTK 3.18.9, GLib 2.48.2, maybe its your GTK version thats the problem.
@elextr Exact same versions here. Have you tried multiple times? Do you consistently get the same `#RRGGBB` in the dialog and in the document?
I have actually traced the source of the problem. It happens because Geany and the `GtkColorSelection` take the same underlying `GdkColor` (0..65535 resolution) and use *different* algorithms to convert it to `#RRGGBB` (0..255 resolution), resulting in a slight discrepancy between what’s shown in the dialog and what’s inserted into the document.
This can be fixed by switching [the two lines in `utils_scale_round`](https://github.com/geany/geany/blob/35a5d457f48c92ecb71b5a2ecf7d718701d5ef63...) and [invoking it](https://github.com/geany/geany/blob/35a5d457f48c92ecb71b5a2ecf7d718701d5ef63...) like `utils_scale_round(... / 65535.0, 255)`. This gives me consistently the same result between Geany and GTK+. (See also `gtk/gtkcolorsel.c`, function `scale_round`.)
The only question, then, is why was the correct line in `utils_scale_round` commented out and replaced with a less correct one. But this [happened before the initial Git import](https://github.com/geany/geany/blob/8cb2cf0997409ec0397efb9554818a733d13f93c...), so probably nobody knows anymore.
I filled several lines with `#RRGGBB` values repeating and changing, and every time its exactly whats in the dialog.
@elextr What about GTK+2?
@vfaronov the `utils_scale_round` was probably changed because the first equation does not handle out of range values.
The problem is the use of binary floating point fractions to represent whole numbers with differing resolutions (a GdkColor has 16 bits per component, `#RRGGBB` has only 8), you get rounding errors, even using double.
@elextr
The problem is the use of binary floating point fractions to represent whole numbers with differing resolutions (a GdkColor has 16 bits per component, `#RRGGBB` has only 8)
Exactly. But GTK+ does this conversion as well — they too have a [`scale_round`](https://git.gnome.org/browse/gtk+/tree/gtk/gtkcolorsel.c?h=gtk-2-24&id=c...) function, and they use the formula that is commented out in Geany.
the `utils_scale_round` was probably changed because the first equation does not handle out of range values.
The first equation is supposed to operate on doubles in the range of 0..1 (GDK’s internal representation, same as in `GdkRGBA` in GTK+3). We can force `color->red` to 0..1 with `color->red / 65535.0`.
Yeah the disagreement in formulas is where the different numbers come from. Have a look at where `utils_scale_round` is used, for win its different, and I think thats where the change happened. Probably should have made two functions, one for gtk and one for windows, but as you say thats lost inthe mists of time.
Should have added, the GTK function actually does scaling, Geanys doesn't, its done in the caller, and no scaling is done for windows.
Right. I’ll check on Windows, maybe the right solution is to use two different functions, for Windows and for GTK+.
Closed #1527 via #1536.
github-comments@lists.geany.org