CODEWITHSUNDEEP
x11
Dibo
Dibo

Reputation: 1189

X11 - How to get system colors?

I'm using X11 lib. Is it possible to get system colors? I mean from current user theme like face, highlight color etc. I can't use GTK and QT libs. Exists any way to get colors by some environment variable or freedesktop?

Regards

Upvotes: 2

Views: 1173

Answers (1)

datenwolf
datenwolf

Reputation: 162299

Prepare for some serious pain and confusion and anger. It could be all so simple, weren't both Qt and GTK+/GNOME serious cases of the NIH syndrome.

In X11 there is a system called X resources database which is effectively a key → value store where key and value are both strings and contained within a property of the root window. You can access it using the xrdb tool. Any well behaved X11 program uses this X resource database to adjust its appearance to that the user set.

The traditional X11 toolkits, Motif, Tk, Athena, Xaw3 and such conformed to this. And everything was well. And because there were set a simple, unambigous set of pattern matching rules nearly every aspect and every single widget could be themed this way.

When GTK+ and Qt were born they too adhered to the Xrdb. But soon the GTK+ and Qt developers said "this is not of our design, we do it our way", so GTK+ and Qt retrieve their settings from dotfiles in the user's homedirectory. And for compatiblity reasons also respect some, but not all, and with every version a different set of Xrdb keys.

Of course desktop libraries ought work together and so a lot of settings mangement systems were born: Elektra, gconf, dconf, uconf, and specifically for X11 Xsettings. gconf, dconf, uconf don't use the X11 protocol of course but propritary IPC or DBus. DBus in itself is rather flawed.

Xsettings however is a specification that's full of contradictions, doesn't work nearly as well as Xrdb does. The main "reason" for Xsettings to be there is, so that clients could be informed about changes, because instead of a property on the root window all the settings were managed by a Xsettings deamon, informing all clients on the screen of a change. And should the daemon die things would go back to default, because clients were supposed to register for the event emitted when the Xsettings daemon's InputOnly property holder window would go away. I have only one word for Xsetting wahrrrgarrrbl.

The Xsettings creators obviously never thought of that changing a window's properties creates a X event by itself, that allows clients to listen for settings changes. Also it makes no sense to get informed about settings changes only, because this requires all clients to keep track of their local settings state, even if some of their internal settings only indirectly depend on some settings. Parsing the whole Xrdb is easier, less error prone and the theoretical overhead savings of only processing a subset of changed settings is in stark contrast that settings don't change all the time.

It's on a long TODO list of mine, to strip Qt and GTK+ of the whole gconf, dconf, uconf, Xsettings and their propriatary config dotfile mess and make them use Xrdb and nothing else.

Upvotes: 6

Related Questions