proposal for extending XSETTINGS registry keys

[Matthias Clasen]

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
a few:

Gtk/ShowInputMethodMenu
Gtk/ShowUnicodeMenu
Gtk/TimeoutInitial
Gtk/TimeoutRepeat
Gtk/ColorScheme
Gtk/TouchscreenMode

You also missed

Net/FallbackIconTheme

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
"hicolor".


> 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 
> environment.

Not really a chicken-and-egg problem, in my perspective. The egg is already 
there. 


> 
> The list of suggested keys are there, in the "Proposed New XSETTINGS Keys" 
> part.

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:


Net/FontName
Net/EnableAnimations

These are fine, no objections to sharing them from the GTK+ side (though
I do think that camelcasing FontName is silly).


Net/ToolbarIconSize

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
in 

typedef enum
{
  GTK_ICON_SIZE_INVALID,
  GTK_ICON_SIZE_MENU,
  GTK_ICON_SIZE_SMALL_TOOLBAR,
  GTK_ICON_SIZE_LARGE_TOOLBAR,
  GTK_ICON_SIZE_BUTTON,
  GTK_ICON_SIZE_DND,
  GTK_ICON_SIZE_DIALOG
} GtkIconSize;


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
implementation:

- 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:
   fg_color, bg_color, 
   base_color, text_color, 
   selected_bg_color, selected_fg_color
 
- 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.


Matthias