dfa1cb7ca5
Previously the editor and palette listened to Gtk.Settings notify::gtk-theme-name (and notify::gtk-application-prefer-dark-theme) to re-render their themed icons on theme switch. Two problems: 1. The initial icon load happened during widget construction, before the buttons were attached to the toolbar — so the style context resolved to a default (often white) foreground rather than the actual theme text color. Icons showed up white until the first theme-change event. 2. Settings notify fires *before* GTK's CSS engine re-resolves styles for the new theme. Reading the style context's foreground from that handler returned the previous theme's color, so toggling light <-> dark left both states settling on the same shade. Move both responsibilities into a new attach_themed_icon helper in _icons.py: it does the initial load, connects to the *button's own* style-updated signal, and rebuilds the icon on each emission. That signal fires *after* CSS resolution (both on first realize and on runtime theme switches), so the foreground we read is always the current one. A per-button color-key guard skips the rebuild when the resolved foreground hasn't changed, so unrelated style-updated emissions (hover, focus, active) don't trigger needless re-renders. The handler is connected to the button itself, so GTK cleans it up when the button is destroyed; both editor.py and palette.py drop their bespoke Gtk.Settings handler bookkeeping. |
||
|---|---|---|
| .. | ||
| cli | ||
| ui | ||
| __init__.py | ||
| configuration.py | ||
| custom_logger.py | ||
| dbus.py | ||
| gtk.py | ||
| i18n.py | ||
| listener.py | ||
| tasks.py | ||
| version | ||