Tk Source Code: View Ticket

Ticket UUID:	23b57a721459528ea9f0fd3f33197f76294e2551
Title:	winfo rgb . systemLabelColor returns a weird result on aqua
Type:	Bug	Version:	9.0, trunk
Submitter:	nemethi	Created on:	2024-10-08 18:47:13
Subsystem:	66. Aqua Window Operations	Assigned To:	marc_culler
Priority:	5 Medium	Severity:	Severe
Status:	Closed	Last Modified:	2024-10-11 14:22:37
Resolution:	Fixed	Closed By:	marc_culler
		Closed on:	2024-10-11 14:22:37
Description:	On the windowing system `aqua` with the normal (light) appearance, the command `winfo rgb . systemLabelColor` returns the list `{0 0 0}` when runing Tk 8.6.15 or earlier. However, with Tk 9.0.0 and the trunk version, the result is a quite weird, random list. After restarting Tk and repeating the command, a different weird result is returned.
User Comments:	marc_culler (claiming to be Marc Culler) added on 2024-10-11 14:22:37: Regarding the deeper problem related to the caching of the RGB values for semantic colors: If you can provide a general solution for it (independently of this ticket), that would be fine. The Widget Demo solves this problem with the aid of event bindings. Please see ticket [01f58bf8f1] and the aqua_colors branch for a proposed fix. I don't know whether it allows removing the virtual event bindings, but I think it should. marc_culler (claiming to be Marc Culler) added on 2024-10-10 22:16:46: That makes sense, and is more or less what the virtual events were intended for. But the values reported by winfo rgb do not change correctly when the window appearance changes. This results from the caching. I avoided dealing with the caching when I added the code to handle the semantic colors. But I have some ideas for how to do it. I think the main issue is that color data is stored using the display and the colormap as fields of the key. But to work correctly on macOS the key should depend on the window and its appearance. I think the colormap (which is not really used for macOS) could be repurposed. nemethi (claiming to be Csaba Nemethi) added on 2024-10-10 11:00:59: Your fix works for me, many thanks! Regarding the deeper problem related to the caching of the RGB values for semantic colors: If you can provide a general solution for it (independently of this ticket), that would be fine. The Widget Demo solves this problem with the aid of event bindings. marc_culler (claiming to be Marc Culler) added on 2024-10-09 15:49:34: Yes, it looks like the code which sets the RGB values in TkpGetColor was omitted for semantic colors on macOS 11 and newer. I created a bugfix branch: bug-23b57a7214. Does that work for you? There is a deeper problem which we should address as well, but probably not in this ticket. That problem is that the RGB values for semantic colors get cached by Tk, with the result that when the appearance changes from light to dark the cached RGB values are all wrong. nemethi (claiming to be Csaba Nemethi) added on 2024-10-09 14:44:05: The bug seems to be somewhere in the function `TkpGetColor()`, in the file `macosx/tkMacOSXColor.c`. I have checked what happens if this function is replaced with its version from Tk 8.6.15, with the result that this time the command `winfo rgb . systemLabelColor` returns the correct list `{0 0 0}`. For me this is a severe bug, among others because it causes the SVG images of the buttons used in the Widget Demo to appear in a strange color rather than in the foreground color of the `aqua` theme. Note that the color of these images is updated whenever a `<<ThemeChanged>>`, `<<LightAqua>>`, or `<<DarkAqua>>` event is received.