Fixes #1527 as discussed there.
In `win32_show_color_dialog`, `utils_scale_round` is not necessary at all because [`Get{R,G,B}Value`](https://msdn.microsoft.com/en-us/library/windows/desktop/dd144923.aspx) already return 0..255, which we can immediately render as hex.
The resulting code behaves correctly for me under all configurations: Linux and Windows, GTK+2 and GTK+3, with or without native Windows dialogs. (The native [Windows color dialog](https://i-msdn.sec.s-msft.com/dynimg/IC534143.png) does not show `#RRGGBB`, but it does show the individual R, G, B bytes, and I checked against those.)
However, I still have no idea why @elextr was unable to reproduce #1527 while I can easily reproduce it in all configurations (with GTK+ color picker).
I’m also not sure why I remember not having this issue in the past, but it’s likely that I only used the color chooser a few times back then, so I may have missed it. You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1536
-- Commit Summary --
* Fix converting color to hex for insertion
-- File Changes --
M src/utils.c (14) M src/win32.c (5)
-- Patch Links --
https://github.com/geany/geany/pull/1536.patch https://github.com/geany/geany/pull/1536.diff
However, I still have no idea why @elextr was unable to reproduce #1527 while I can easily reproduce it in all configurations (with GTK+ color picker).
Maybe some versions of GTK do something different or maybe it depends on the version of colour chooser your distro provides, there are two, the traditional sane one and a dumbed down version thats useless?
Anyway LGBI.
@elextr
I think the dumbed down version is a different API — [`GtkColorChooserDialog`](https://developer.gnome.org/gtk3/stable/GtkColorChooserDialog.html) (new in GTK+3) — while Geany only uses the traditional [`GtkColorSelectionDialog`](https://developer.gnome.org/gtk2/stable/GtkColorSelectionDialog.html) ([deprecated in GTK+3](https://developer.gnome.org/gtk3/stable/GtkColorSelectionDialog.html#gtk-col...)).
By the way, when you tried to reproduce this, did you select the color by clicking on the ring/triangle, or did you directly adjust the individual inputs like H/S/V? It could be that only the ring/triangle have enough resolution to trigger this issue.
I think the dumbed down version is a different API — GtkColorChooserDialog (new in GTK+3) — while Geany only uses the traditional GtkColorSelectionDialog (deprecated in GTK+3).
There have been reports of the dumb one appearing in Geany, so thats not it, anyhow so long as the sensible one continues to be available I don't care.
By the way, when you tried to reproduce this, did you select the color by clicking on the ring/triangle, or did you directly adjust the individual inputs like H/S/V? It could be that only the ring/triangle have enough resolution to trigger this issue.
Yes, but I may have just been lucky, after more testing it failed a couple of times, maybe 1 in 5.
@elextr
after more testing it failed a couple of times, maybe 1 in 5
Ah, that’s about my rate, too. OK then.
Tested on Windows with native color dialog and looks good to me.
Any objections in merging this before the release? If not, I would merge it tomorrow or on Thursday.
Any objections in merging this before the release? If not, I would merge it tomorrow or on Thursday.
Seems ok on Linux, so since colour chooser isn't a critical part of Geany seems ok to merge before release.
OK with me as well (@eht16 ping)
Merged #1536.
Thanks!
Thank you for fixing :)
github-comments@lists.geany.org