Re: GtkBuilder Public API - Last call

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

2007/6/14, Yevgen Muntyan <muntyan tamu edu>:
> Kalle Vahlman wrote:
> > Is there a particular reason to set the name in _init() rather than in
> > _set_cursor_colors()? It would avoid setting it completely if using
> > Gtk+ >=2.11.3
>
> Code was written before Gtk+ >= 2.11.3.

...with a chisel to a stone I gather ;)

> > and since it does nothing(?) if the custom colors are
> > not set...
> >
> > Also, why is it neccessary when the colors are not set explicitly?
> > Isn't the class name as good as any for setting default values in
> > themes?
>
> What's necessary? Let's not consider funny cases when nothing changed,
> think white cursor and white text color and black background in a usual
> black-on-white gtk theme (people actually do use dark themes, it's not
> some academic exercise about how to override theme colors).

I meant, why does the widget need to have the unique name even if the
cursor colors are not set? Maybe I missed that but I didn't see it set
anywhere in the initialization code so the unique name matches to
exactly nothing until someone sets it.

> >> The GtkSourceView code (and code above) was an example
> >> of code which uses unique widget name to modify style property,
> >> since you didn't seem to believe it is possible and may be
> >> needed.
> >
> > I never said it wouldn't be needed. I'm just saying that there is no
> > reason to do it in construction stage,
>
> You were talking about class matching and whatnot, so I got
> that impression. Anyway, one possible reason is that constructor
> and init() are natural places for things which are done once for
> whole life of the widget. Another reason is that one may still
> change the name if he knows what he's doing (GtkBuilder doesn't
> and it's what sucks). Dunno, it just happened so. Now, "If you want
> the widget to be used with GtkBuilder you must not set widget
> name until after construction. Why? No reason really, just because."
> It's silly.

Because the user gave it a name in the xml and would possibly like
that to be matchable from a gtkrc? If the application explicitly sets
the cursor color, well, then it's bye-bye for the end-user theme I
guess...

> > since it will not give you
> > anything over matching by class.
>
> That setting is *per-widget*, not per-class.

Unless it's not set, which means either the default value or the value
from any parsed gtkrc. Which was my point.

> > If you need to hack styles in later,
> > you can set the name then and hope the user doesn't go and change it
> > afterwards. Also you can hope that the user didn't want to customize
> > the theming of that widget by his own account and get angry at you
> > since the widget changes it's name making it impossible...
>
> So there are possible problems (of course), so I shouldn't mind
> one more possible complication? Note that this latter complication
> is not related to theme business (as opposed to user changing styles
> manually and breaking things), it's just some strange function
> call in a place seemingly unrelated to the theme business.

"manually" as in gtkrc? I consider that the authority when it comes to
what style settings should be obeyed, if the application overrides
that... well. I guess it's your application.

For the record, I do understand[1] why the unique names and styles are
used. But since it is very error prone and unfriendly to themes when
done *inside* widgets (or even applications), I don't think it's worth
blocking a natural expectation of the user of GUI editors; that the
"Name" field in the editor will really be the name of the widget which
you can use in gtkrc:s for your own theming options.

If you now understand my POV (that's all I'm after), we could just
stop here (it's not like this is really constructive anymore ;)

[1] though I don't really agree on widgets setting colors at all,
regardless the fact that it then possibly won't look good with older
themes (depending on what colors you can use).

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