Re: GtkBuilder Public API - Last call
- From: Yevgen Muntyan <muntyan tamu edu>
- To: zuh iki fi
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: GtkBuilder Public API - Last call
- Date: Thu, 14 Jun 2007 02:58:29 -0500
Kalle Vahlman wrote:
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?
See
http://svn.gnome.org/viewcvs/gtksourceview/trunk/gtksourceview/gtksourcestylescheme.c?view=markup
for cursor color thing, set_cursor_colors() function. For non-unique
name, try
to get tooltips color on your widget without "gtk-tooltips" name.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]