proposal for extending XSETTINGS registry keys
mclasen at redhat.com
Wed Mar 28 11:07:36 PDT 2007
On Wed, 2007-03-28 at 18:58 +0200, Marius Bugge Monsen wrote:
> On Wednesday 28 March 2007 17:39, you wrote:
> > On Wed, 2007-03-28 at 16:46 +0200, Marius Bugge Monsen wrote:
> > > Hi all,
> > >
> > > At the Desktop Architects Meeting 3, beginning of December last year,
> > > Waldo asked me if I could write a proposal for extending the XSETTINGS
> > > registry keys.
> > I'm not sure there is a big need for extension here, though, and I'm a
> > bit wary of extending the spec before it is even used in more than one
> > toolkit. The important step here is to actually have a second xsettings
> > implementation using the current keys, then we can have a careful look
> > at what Gtk/ keys can be shared.
> As you say, XSETTINGS was intended as a cross-toolkit settings mechanism.
> For this to work, though, the settings keys also need to be toolkit
> independent (as is the intention with the Net/ keys).
> The Gtk/ keys are basically a mapping of GtkSettings properties, and may not
> always make sense for other toolkits.
It is not quite like that, the GtkSettings properties have been mapped
to Gtk/ Xsettings where it makes sense, but there are some exceptions,
e.g. settings which are mostly controlling better win32 emulation.
Looking again at your list of Gtk/ XSettings, I notice that you missed
You also missed
which I may not have added back to the xsettings spec yet. This is the
icon theme to use as final fallback after inheritance, default being
> As it is now, I think the set of Net/ keys is just to small to be really
> useful. An application will always need to get additional desktop-related
> settings elsewhere.
> I realize that it is in some ways a chicken-and-egg problem, but I think that
> it will be easier to get other toolkits to support XSETTINGS if the set of
> Net/ keys is complete enough to allow good integration with the desktop
Not really a chicken-and-egg problem, in my perspective. The egg is already
> The list of suggested keys are there, in the "Proposed New XSETTINGS Keys"
Ok, I hadn't read far enough.
> I'd still say that there is a need to find a toolkit independent way to set
> the color palette for the applications on your desktop.
Maybe that is so, but the right setting to study for prior art here is
Gtk/ColorPalette, which is what gtk+ exposes as an xsetting, not
GtkSettings::color-hash, which is an implementation detail.
Looking at the proposed keys:
These are fine, no objections to sharing them from the GTK+ side (though
I do think that camelcasing FontName is silly).
You silently changed this from an enum to an int. The way toolbar sizes
work in GTK+ is that Gtk/ToolbarIconSize specifies an enumeration value
and Gtk/IconSizes specifies a mapping from names for these enumeration
values to sizes, like gtk-menu=16,16:gtk-button=20,20...
This added indirection allows e.g. to change between large and small
toolbar icons, while the theme determines the actual pixel sizes that
correspond to large and small (gtk settings can also be set by themes).
Proposed keys for colors
This is the bulk of your proposal, and I'm not really happy with it :-(.
You seem to be saying "GTK+ has prior art in this area, but we'll just
ignore it and make up our own". What is the reason for not at least
considering the Gtk/ColorScheme way of specifying a color-scheme ?
Some notable differences between your proposal and the GTK+ color scheme
- You have a fixed set of separate keys, the GTK/ColorScheme setting
allows an arbitrary set of named colors, with the idea that theme
authors will agree on a reasonable set of standard names, but the
mechanism is flexible to adapt to future changes and special needs.
The current set of names that are used in the recolorable themes in
Gnome 2.18 is:
- You have folded (some) states in the set of color keys. First of all,
I do not see how this can work at all, if the sets of states are not
the same between different toolkits. You simply left out the GTK+
states that have no Qt counterpart - what are GTK+ theme engines
supposed to do, make up colors for the missing states ?
Also the semantics of GTK+ widget states are not defined clearly
enough to make such global color settings feasible. If you look at
GTK+ theme rc files, you will notice that themes typically change
colors for individual widgets. The Gtk/ColorScheme setting was
designed to work with this situation by treating the color-scheme
as input to the theme, and allowing rc files to refer to colors
set by the color-scheme.
- Your color keys have type int (I guess you envision some
RRRRGGGGBBBB hex encoding for colors here ?), whereas Gtk/ColorScheme
accepts color names too, allowing you to write e.g.
selected_fg: DodgerBlue. That may not be too relevant for
the XSetting, but it is definitively nice when setting a value
for the setting from an rc file.
More information about the xdg