Are Out-of-Tree Widgets Second-Class Citizens?
- From: Morten Welinder <mortenw gnome org>
- To: "Gtk+ Developers" <gtk-devel-list gnome org>
- Subject: Are Out-of-Tree Widgets Second-Class Citizens?
- Date: Mon, 28 Sep 2009 15:12:16 -0400
A long time ago GTK+ was a collection of widgets. If you did not like
what you had,
you could grab the source of one of the widgets and change it to do whatever you
needed it to do.
This is increasing no longer the case -- in-tree Gtk+ are now special
and programmed
using a different API than out-of-tree widgets. This is wrong!
Consider GtkLabel as exhibit 1. This is the vanilla flavour of
widgets. I should be
able to copy gtklabel.[ch] into my tree, rename all identifiers and
end up with a
new widget functionally identical to GtkLabel. It does not work because it will
not compile. GtkLabel is using, for example, things like "widget->window" and
"widget->allocation".
This is a consequence of the halfway G_SEALing that was done. Insofar G_SEAL
is a good idea, it should apply to GTK+ itself, i.e., GtkLabel has no business
messing with the internals of GtkWidget, although obviously it should
have access
to its own internals. (Doing so would also send some of the conversion pain
back to people who inflict it on others. That might discourage the habit of
breaking APIs and ABIs without good reason.)
Consider now GtkRadioButton as exhibit 2. This would probably be the chocolate
flavour. Note, that GtkRadioButton is derived from GtkToggleButton.
You cannot
make a copy of GtkRadioButton for several reasons: First, G_SEAL makes it
impossible to set GtkToggleButton::active which is something that
gtk_radio_button_clicked has a reasonable interest in doing. There in a
setter function, gtk_toggle_button_set_active, which does the same as setting
the property, but it just calls the clicked method -- instant infinite
recursion.
Secondly, the code uses various _gtk_* methods that were, evidently, useful
enough to implement a small handful of widgets but not useful enough to make
public. I am not sure how you would work around the lack of
_gtk_button_set_depressed, for example.
So there you have it:
1. Please make G_SEAL apply also within GKT+.
2. Please stop using _gtk_* functions to be extra friendly to in-tree widgets.
(There are likely a few places where _gtk_* functions make good sense: the
interaction between widgets and size-groups comes to mind.)
Morten Welinder
PS: I did find a way to set GtkToggleButton::active for Gnumeric. Let us just
describe it as "not pretty."
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]