proposal for extending XSETTINGS registry keys

[Marius Bugge Monsen]

On Thursday 29 March 2007 16:33, you wrote:
> 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 would be a way to solve it.
One way to make it clear that the semantics are different, is to give the Net/ 
keys different names from the Gtk/ keys.

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

For GNOME I guess this is not a problem, since the theme decides the color 
palette. However, in KDE it is possible to change the color scheme 
independent of the style. It would be good if it was possible for 
applications using XSETTINGS to adapt when the user changes the color scheme 
of the desktop.
Note that a KDE color scheme would not have an equivalent GNOME color scheme.
I believe the best approach is to have keys for the color values.

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

I agree that it's a good idea to go through the current keys and write down 
the semantics.

As for icon sizes, here are the icon pixel metrics defined in Qt (QStyle):

PM_ToolBarIconSize,
PM_ListViewIconSize,
PM_IconViewIconSize,
PM_TabBarIconSize,
PM_ButtonIconSize,
PM_SmallIconSize,
PM_LargeIconSize

The actual sizes are typically either the PM_LargeIconSize or 
PM_SmallIconSize.
I'm not sure about how this works in Gtk+, but maybe we only need 
Net/SmallIconSize and Net/LargeIconSize.

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

Cool.

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

Sure, but the names has to be defined in the theme. If my Qt app is using the 
CleanLooks style to emulate the Gtk+ Clearlooks theme, it needs to get the 
colors from somewhere.
Whether each color has a separate key or the palette has a key can be 
discussed. But it should be possible to get the color values, not just names.

<snipp>

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

Ok, Gtk/ColorScheme is not listed in the spec on freedesktop.org yet.
However, the end result, after looking up colors in the hash and mixing them, 
is that the style has a set of colors that is used to draw the UI, right ?
And the XSETTINGS manager knows enough to provide those color values in 
addition to the Gtk/ColorScheme, right ?
So why not present the color values directly, for those applications that just 
want to use the right color values when drawing ?

Out of curiosity: what is the relationship between Gtk/ColorScheme's 
selected_bg_color, selected_fg_color and GtkStyle's fg[Gtk::STATE_SELECTED], 
bg[Gtk::STATE_SELECTED] ?

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

I agree.
Essentially, the color keys will just present the same information in a 
different format; instead of having the ColorScheme and the Theme palette,
it just presents the color values directly.
A Gtk+ application could keep on using the Gtk/ keys if they are available.

<snipp>

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

Well, Gtk+ has a Selected state, but Qt, has palette entries for selected 
colors (eg. QPalette::Highlighted and QPalette::HighlightedText).
If everything except the background and text color is the same, why duplicate 
all the color keys for selected items ?
This is one of the areas where the toolkits are different, and we just have to 
come up with a good compromise. :)

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

Great! I'm looking forward to reading it.


Cheers,
Marius