2007/6/14, Yevgen Muntyan <[EMAIL PROTECTED]>: > 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, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
