<div class="gmail_quote">On Mon, Mar 26, 2012 at 7:09 PM, Simon McVittie <<a href="mailto:simon.mcvittie@collabora.co.uk">simon.mcvittie@collabora.co.uk</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">On 26/03/12 18:26, Jerome Leclanche wrote: > FWIU, xsettings > is a way of storing the data -- this standard defines the data to be stored. </div>No, xsettings is a way of accessing the data at runtime. The "storage" in xsettings is transient (X window properties), so it's more like "use xsettings instead of D-Bus" than "use xsettings instead of ~/.config/whatever". The actual persistent configuration is an implementation detail of the settings manager; in GNOME 3, gnome-settings-daemon is the settings maanger, and it appears to read them from org.gnome.desktop.interface in DConf. In GNOME 2 they were probably in GConf instead. The point of using xsettings is that the settings are per X session (even in the presence of remote apps, or changes being made during an app's lifetime), as opposed to, say, being per home directory. If I run an application via remote X, it uses the same theme, double-click timeout, (etc.) as the local applications it shares an X session with, rather than reading these settings from the remote home directory and potentially getting different values. The initial use cases for xsettings given in the spec are "double click timeout, drag-and-drop threshold, and default foreground and background colors" - Gtk themes presumably came later. (I'm not saying that having settings managers get their settings for theme or double-click time or whatever from the same place wouldn't be a good thing, or expressing any opinion about where the Gtk theme should be stored; just pointing out that the use of xsettings has semantics that would not be provided by each app reading from its home directory.) S </blockquote></div><div> </div><div>Ah, I see. This is out of my league though; if someone wants to propose an addendum I'm not against it, but I still don't see it being too relevant to this spec, more of an implementation detail.</div> J. Leclanche