Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
3 check-ins related to "x11-appearance"
|
2026-10-26
| ||
| 18:30 | Merge x11-desktop-portal, whose D-Bus layer the implementation of TIP 767 builds on: [::tk::portal::_call] for reading org.freedesktop.portal.Settings, and the connection's place in the event loop for SettingChanged. check-in: 9a9f1f72 user: serhiy.storchaka tags: x11-desktop-appearance | |
| 18:18 | Implement [wm attributes $w -appearance] and [winfo isdark] on X11, as TIP 766 proposes. TIP 750 left both out here: the attribute was rejected as a bad attribute, and the command always returned false, because X11 gives a window no appearance of its own. What a window does have is the colour it is painted, and that colour can already be dark: a desktop or a user who wants dark applications says so in the X resource database, which Tk has always obeyed. So [winfo isdark] now reports whether the window's background is a dark colour, by the weighting tk_setPalette uses to choose between a black and a white foreground, and answers from the attributes Tk records rather than realizing the window. The attribute applies a palette: light and dark are tk_setPalette's, over the background Tk has always had and a dark counterpart, and auto is the palette which was in effect before the attribute was first set, remembered for the purpose and restored exactly, including the colours Tk has compiled in rather than computed. Only the colours which go with the background change. The selection colours are supplied rather than computed from it: an accent goes with a light frame and a dark one alike, and the classic widgets and the themed ones have each had their own, which tk_setPalette on its own would replace with a shade of the background six units from the frame. Because the option database has no per-window scope, the palette is the application's and not the window's, which the tests state on both sides. seedColors takes the colours its caller imposes as an argument, so that the rules which follow the selection keep one home. Three tests of the attribute which were portable but lived in the Windows-only file move to wm.test, the duplicate of the usage test goes, and the check that [winfo isdark] follows the attribute loses the constraint which kept it off X11. leaf check-in: 76acab2c user: serhiy.storchaka tags: x11-appearance | |
| 12:31 |
Fix for [807b2f8916]: compute the colours of the default ttk theme which no X resource supplies.
A desktop which translates its theme into X resources generally sets only background and foreground, which reach three of the theme's thirteen colours. The rest kept values chosen for a light grey palette, so a dark background was left beside a near-white -activebg and a light -darker: the text of a hovered button became illegible. Compute them instead from the colours the option database does answer for, by the rules tk_setPalette applies to the classic widgets, so that the two agree. The selection colour is not computed: it is an accent rather than a shade of the frame. Four of those rules are factored into ::tk::ContrastColor, ::tk::Lighten, ::tk::BlendColors and the existing ::tk::Darken, which tk_setPalette now calls instead of writing them out; its output is unchanged. ::tk::Darken scaled a component down to eight bits before applying the percentage, losing up to a unit, and now divides once. leaf check-in: d0c3cb85 user: serhiy.storchaka tags: ttk-derive-missing-colors | |