Re: GtkBuilder Public API - Last call

["Kalle Vahlman" <kalle vahlman gmail com>]

2007/6/14, Yevgen Muntyan <muntyan tamu edu>:
> Kalle Vahlman wrote:
> > 2007/6/13, Yevgen Muntyan <muntyan tamu edu>:
> >> Kalle Vahlman wrote:
> >> > 2007/6/13, Matthias Clasen <matthias clasen gmail com>:
> >> >> GtkBuilder is just setting the name that was specified in the xml, so
> >> >> it is not violating the principle that the widget name belongs to the
> >> >> app/user, since
> >> >> the xml is part of the app.
> >> >>
> >>
> >> And widget isn't part of the app? Such separation is meaningless for
> >> purpose of answering the question "should we change code of given
> >> widget if we want the widget to be usable with GtkBuider?"
> >>
> >> So, if a widget sets its name to modify its style, then
> >> it's broken? Even if the style is essential part of its functionality?
> >> E.g. text cursor color is not something fancy, it's an essential part
> >> of text widget and it rather sucks if cursor is invisible because of
> >> wrong styles. Saying "it's broken because it is somehow
> >> not a part of application" just doesn't make sense.
> >
> > So let's see, the things that make up a "style" in gtkrc are colors
> > and style properties. Any special-casing above (or rather below) that
> > is up to the theme engine and thus can't really be trusted. Colors are
> > grouped by functionality into fg, bg, base and text (as well as the
> > various computed colors from those). Those have clear meanings, and
> > should provide enough distinct colors for most widgets. If not, you
> > must rely on custom style properties and accept that it might not
> > match the theme. There is no way around this (other than calculating
> > the color, but that might be less than pleasing visually).
> >
> > If a widget goes bonkers because a style property had the default
> > value, maybe the default value should be made more sensible?
>
> Until gtk-2.12 there was no API to set cursor color. Try a textview
> with black background and black cursor and you'll see what I'm
> talking about ;)

But I don't understand why this has anything to do with widget names?
If you set black on black, it'll be black on black even if you widget
is named "GreyOnWhite".

> Try to get tooltips yellow color from a theme, without using
> "gtk-tooltips" name.

But GtkBuilder doesn't touch that name? So why would it break?

> And of course those custom style properties won't match theme,
> why would one change them otherwise? Thing is, sometimes you
> do need to change those style properties, and it is *not* something
> wrong or evil.

Let me see if I can list the cases where this is neccessary:
- You implemented your custom widget and it needs style
   -> match by *.class
- You implemented a custom container and wish to give style to the children
   -> match by *.class.child_class
- You implemented a custom widget with internal children and they need style
   -> name the internal child whatever and match by name
- You need to set style to it here but not there
   -> name the widget you get from GtkBuilder and match by name

Is there other cases, and why do they break down if GtkBuilder sets the name?

> > You said that matching the widgets in gtkrc would be a problem and in
> > the part that you didn't include here I told you it's not:
> >
> > "A quick test shows that I can indeed match my widget by the fancy name
> > I gave it in the code in a gtkrc, while the lookup returns the correct
> > object with the xml id."
> >
> > Did I miss something obvious here? Or did you?
> >
>
> Set widget name in constructor or init(), then create this widget with
> GtkBuilder.
> Yeah, "semi-broken".

Why is that preferrable over matching by the widget class name?

--
Kalle Vahlman, zuh iki fi
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi