Re: Gtk3 and theming - a proposal (with code)

["Robert Staudinger" <robert staudinger gmail com>]

On Fri, Oct 10, 2008 at 6:22 PM, Alberto Ruiz <aruiz gnome org> wrote:

[...]

> I think that the new API should not allow people to acess to
> GtkWidget, this prevents implementation changes since engines end up
> depending on Widget implementation details (such as the way containers
> are used and where in those containers are the elements placed, I'm
> thinking in "TreeView > Label" precedency use case here). I think
> GtkStyle should go away and be replaced by something that would
> provide this information.

The problem with this approach is that if you disallow accessing the
widget instance, engines can only ever do things that have been
thought of /before/. The CSS engine would not have been possible like
that, you really want a "constructionist" API, that allows for
tinkering.

If the nesting of a composite widget is part of the stable gtk API,
why whould the themes not be allowed to just as well rely on it?

> Another huge annoyance is the inability to provide information about
> siblings, at the moment, the only way to inform about those things is
> the detail string, and once is set, you can't change it. We couldn't
> use most of the css selector patterns such as "Label + Entry" or
> "Notebook.tab:first-tab". Again, the GtkStyle replacement should
> provide that context information.

GtkStyle is not to blame, it's the containers/widgets that don't
export this information. In any case, if you'd like to provide the
ability to match against arbitrary widget trees you'd really have to
instantiate an abstract representation of the widget nesting from each
toplevel down to the non-containers, including all the widgets' style
properties. The option of restricting matching depth to some arbitrary
number does not sound like a solution.

- Rob