proposal for extending XSETTINGS registry keys

[Marius Bugge Monsen]

On Wednesday 28 March 2007 20:07, you wrote:
> 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.

If we are only talking about the XSETTINGS registry keys, from my perspective 
it is not. :)
I'll try to clarify:
Toolkits other than Gtk+ should not have to care about the Gtk/ keys. They 
should only have to care about the Net/ keys. The current set of Net/ keys is 
very limited, and does not have any color palette keys. That means that 
supporting XSETTINGS will not give you much in terms of helping integrating 
your application with the desktop environment.

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

Entries in the Gtk/ColorPalette are not the same as the palette entries in 
other toolkits.
Having one settings key for each color may or may not be the right thing to 
do, but I think we need to decide on a set of cross-toolkit color roles that 
should be defined in the color palette.

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

I have absolutely no problem with changing that to Net/Fontname. :)

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

I'm not sure I see what you gain by having this indirection reflected in the 
XSETTINGS registry keys. Especially since the enums are specific to Gtk+.

>
> 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 ?

All tookits have their own palette format with their own color roles and 
states. If the ambition is to have other toolkits support XSETTINGS, no 
toolkit should force its format on the others. We should rather strive for a 
common set that can be used by all. I'm sure it is possible.

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

I have to admit that I have only looked at Gtk+ 2.10.11 (released 14 March 
2007). There selected_bg_color and selected_fg_color are not present in the 
GtkStyle struct there.

This is not just about having non-Gtk+ application integrating with the GNOME 
desktop. It should also work the other way around. If KDE should adopt 
XSETTINGS, it would be nice if Gtk+ applications looks and behaves like the 
rest of the apps on the desktop. :)

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

The only Gtk+ state that was not part of the suggested palette states was 
Gtk::Selected. Instead I added Net/Selected* keys. These keys should cover 
the usecases where selected items are involved.

I've experimented a bit with the Gtk+ states, but I'm not quite clear on when 
the Gtk::Selected state is set on a widget. But, hey, if there are solid 
arguments for having a Selected state too, I'm not religious about not having 
it.

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

Ok, to sum up a bit:
The Net/Fontname and Net/EnableAnimations keys are ok.
We need closer at the type on the Net/ToolbarIconSize key.
We need to discuss the color keys some more.
Sounds about right ?


Cheers,
Marius