proposal for extending XSETTINGS registry keys

[Matthias Clasen]

On Thu, 2007-03-29 at 14:45 +0200, Marius Bugge Monsen wrote:

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

But you realize that there will be a bit of a problem for GTK+ if you
now invent new Net/ keys for things that GTK+ has already covered, but
with subtly different semantics ? We would probably have to prefer the
Gtk/ keys and only fall back to using the Net/ keys if there is no Gtk/
specific implementation. 

>  That means that 
> supporting XSETTINGS will not give you much in terms of helping integrating 
> your application with the desktop environment.

Sure it does. It does not give you detailed color scheme information,
that is true. But until recently, the theme name was good enough to give
you at least a chance to adapt the visual appearance of applications.
Provided the themes are available cross-deskop a la Bluecurve.
 
> > 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+.

Sure, I didn't mean to propose this for the Net/ key, I just wanted draw
attention to the fact that your proposed Net/ key has different
semantics (reinforcing my opinion that writing down the semantics of the
current Net/ and Gtk/ keys is a necessary prerequisite for this
discussion). My explanation of the Gtk/ToolbarIconSize key hopefully
shows that adding a key for the toolbar iconsize in isolation is of
dubious value, since you really want to adjust the sizes of all icons
(menus, buttons, toolbars, etc) together.
 

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

Right, please don't take my comments as opposition to the general idea
of sharing color schemes, I'm just trying to explain how GTK+ works
currently. 

I'd like to point out again that Gtk/ColorScheme does not force any
color roles and palette formats on anybody. It is just a map from
names to colors, with an arbitrary set of names. 

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

They are not, because (as I explained in my previous mail) the colors
defined in the Gtk/ColorScheme settings do not map directly to GtkStyle
fields. They are used as input in the theme's gtkrc file, which can 
defines the style colors using simple color expressions like 
mix(0.9, "DodgerBlue", @fg_color) (this one means: the fg_color from the
color scheme, mixed with a bit of dodger blue).

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

Right. Which is why it is important to come up with a way of specifying
colors that can be retrofitted into the existing GTK+ color scheme
handling.

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

If you want to refer to states at all in the color keys, it would
certainly be more consistent to have Selected as a state. 

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

That about sums up my initial response. The icon size thing should not
be limited to toolbars though, as pointed out above. 

I'll try to sit down sometime this week and write up some explanations
of the semantics that the current keys have in GTK+.


Matthias