Re: API Change request: gtk_paint_focus and GtkStyleClass->draw_focus
- From: Owen Taylor <otaylor redhat com>
- To: Bill Haneman <bill haneman sun com>
- Cc: gnome-2-0-list gnome org, gtk-devel-list gnome org
- Subject: Re: API Change request: gtk_paint_focus and GtkStyleClass->draw_focus
- Date: 01 Dec 2001 18:28:43 -0500
Bill Haneman <bill haneman sun com> writes:
> Hi All:
>
> I mentioned an API issue embedded in my outstanding theme patch for
> GTK+ yesterday. Here are the details. [...] It requires the
> following API change to gtk_paint_focus, and to the draw_focus
> method of GtkStyleClass:
>
>
> void
> gtk_paint_focus (GtkStyle *style,
> GdkWindow *window,
> GdkRectangle *area,
> GtkWidget *widget,
> + GtkStateType state_type,
> const gchar *detail,
> gint x,
> gint y,
> gint width,
> gint height)
OK, thought about this some now. I see 2 ways of avoiding an API
change here:
* Just always use widget->state. The results really aren't bad;
we only have problems:
- If we area drawing a "subwidget" that has a state
independent of the widget
- If the foreground in the state of the subwidget is
significantly different from foreground of the
state of the widget.
- If focus indication is necessary for the subwidget.
Examples do exist - an example might be a black-and-white high-contrast
theme where selected rows of are drawn in black on white and other
rows white on black - but they certainly aren't common.
* A gross hack -- callers that need to paint with something
other than widget->state can do:
GtkStateType saved_state = widget->state;
widget->state = subwidget_state;
gtk_paint_focus (style, window, area, widget, ...);
widget->state = saved_state;
We could also do this as a compatible API change:
* We add gtk_paint_focus_extended() and a paint_focus_extended()
virtual function to GtkStyle. (Default implementation of
paint_focus() calls paint_focus_extended().)
[ This would be the route we'd take if we were making the same change
for GTK+-2.2. ]
> gtk_paint_focus is called 17 times in gtk+. The only use I have found
> outside gtk+ in gnome libraries is in gal/e-text, where it appears
> twice. It does not seem to appear in eel, gnomeui, or other UI libs.
Are you familiar with cvs.gnome.org/lxr/. The searching there is
sometimes a little wonky, but in this case, the identifier search turns
up uses in:
ggv, gnomeicu, granite, gnome-applets, rp3, galeon, bonobo-config,
bonobo-conf, metacity
In addition to gal and GTK+.
Of these only gnome-applets, bonobo-config, and metacity, are
currently targetting GTK+-2.0. The relevant code in bonobo-config and
gnome-applets is not currently compiled, so of things in CVS, only
metacity actually breaks currently. (And on the vtable end,
pixbuf-engine.) But it's certainly a real API change causing real
incompatibilities.
Still, I can't really claim that any of the three solutions listed
above actually benefits GTK+ users more than just going ahead and
making the change, fixing up uses on CVS, and documenting it in the
release announcement for 1.3.12. (Though they might be more gentle
to my pride in being able to stick to an API freeze.)
So, unless people have convincing arguments otherwise, I'll go ahead
and make the change.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]