Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
6 check-ins related to "x11-desktop-appearance"
|
2026-10-26
| ||
| 21:34 | Leave the appearance the application chose alone. Following the desktop was moved to the first idle so that no window is made while Tk is still initialising, but an application which sets [wm attributes . -appearance] while it starts up then had its choice undone a moment later, the deferred call applying the desktop's scheme over it. It now applies the desktop's scheme only where the appearance is still the one it was given, which is the condition the change handler already uses. leaf check-in: 6c5d2af7 user: serhiy.storchaka tags: x11-desktop-appearance | |
| 21:14 | Follow the appearance the desktop asks for, as TIP 767 proposes. The colour scheme, the accent colour, the contrast and the reduced-motion preference are read from the org.freedesktop.appearance namespace of the XDG desktop portal, through the D-Bus client of the x11-desktop-portal branch, which is merged here: [::tk::portal::_watch] is added to it for the SettingChanged signal, which arrives while messages are dispatched and so is handed to the script by way of an idle handler rather than run there. [tk appearance] reports the settings and changes nothing, every one of them answered for whether the portal answers or not. The "auto" value of [wm attributes -appearance] now follows the scheme, the desktop's accent becoming the selection colour, while a colour the user chose in X resources outranks both, the database being read before Tk writes a palette of its own. The events of TIP 750 are sent when the desktop changes its mind, whatever the attribute's value, and the palette follows where it is "auto". The appearance is applied once the application is up rather than while Tk is still initialising: applying a palette makes a window of its own, and making one during initialisation leaves the selection tests failing, a different one each time. Where no session bus is named none is started to look for one, a toolkit having no business launching a bus while it starts up. Also merged: the fix of [1c51656171], without which a palette which is switched back and forth leaves the windows made before and after a switch disagreeing. check-in: a85527b5 user: serhiy.storchaka tags: x11-desktop-appearance | |
| 19:08 | Fix for [1c51656171]: add the tests for tk_setPalette, left out of [255fe59706] because a new file is not committed until it is added. leaf check-in: e64ae55c user: serhiy.storchaka tags: tk-setpalette-recolor | |
| 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 | |
|
2026-10-23
| ||
| 18:00 | Merge trunk leaf check-in: 430b18f4 user: kevin_walzer tags: x11-desktop-portal | |