GtkSizeGroup
- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list gnome org
- Subject: GtkSizeGroup
- Date: 08 May 2001 09:15:33 -0400
I spent some time reviewing GtkConstrain and GtkKennel
http://bugzilla.gnome.org/show_bug.cgi?id=50299
yesterday, to try and move towards getting something like
this into GTK+.
Looking these over, it seemed to me:
* Using an extra container widget, as GtkConstrain does
is annoying for the user. Also, it doesn't allow completely
correct behavior without some hooks into the internals
of size allocation.
Trying to do everything by attaching to the constrained widgets
size_request handler, as GtkKennel does, is highly hackish and
complicated. Also, it probably doesn't allow completly correct
behavior without some hooks into the internals of size allocation.
(E.g. GtkKennel uses an idle handler to handle propagation of
resizing through the group, and doesn't handle set_usize())
So, it seems it is best to do this as a facility built-in
to GTK+, though this doesn't need to be exposed in the
API. (And isn't in the API I propose)
* GtkConstrain[t] as a name is probably going to lead people
to believe that it actually forces all the widgets to be
the same size, instead of just coordinating the requisitions.
GtkKennel just doesn't make much sense to an English speaker.
So, the name I came up with is GtkSizeGroup.
* GtkKennel allows four different types of operation
"MINIMUM" "MAXIMUM" "TO_WIDGET" and "TO_USIZE" for each
dimension
- MINIMUM - minimum of all the widgets' requisitions.
- MAXIMUM - maximim of all the widgets' requisitions.
- TO_WIDGET - to some particular widget? (not implemented)
- TO_USIZE - to a fixed size.
My proposal has only MAXIMUM, because I believe making a
widget smaller than its requisition is very seldom useful,
which means that MAXIMUM and TO_WIDGET are very seldom
useful.
Similarly TO_USIZE can be achieved by simply setting the size on
one widget (or setting the same size on all the widgets and not
using a constrain group...)
* Memory management: make GtkSizeGroup a GObject, have the widgets in
the size group ref the size group, and make the reverse connection
a weak reference.
* There will be cases where it is useful to have a widget be
part of multiple size groups. (E.g., one horiziontally, one
vertically.)
In allowing this, it's probably worth going the full route
and allowing complicated setups where A and B are horizontallly
grouped and B and C are horizontally and vertically grouped,
and do the calculations to group A and C horizontally as well.
This does lead to some more internal complexity, but its
not EXTREME complexity and better, I think, than a ad-hoc
partial handling of the situation.
I've started work on implementing the interface below; hopefully
it won't take more than a day or so to do.
Regards,
Owen
====
typedef enum {
GTK_SIZE_GROUP_HORIZONTAL,
GTK_SIZE_GROUP_VERTICAL,
GTK_SIZE_GROUP_BOTH
} GtkSizeGroupMode;
GType gtk_size_group_get_type (void) G_GNUC_CONST;;
void gtk_size_group_new (GtkSizeGroup *size_group,
GtkSizeGroupMode mode);
void gtk_size_group_set_mode (GtkSizeGroup *size_group,
GtkSizeGroupMode type);
GtkSizeGroupMode gtk_size_group_get_mode (GtkSizeGroup *size_group);
void gtk_size_group_add_widget (GtkSizeGroup *size_group,
GtkWidget *widget);
void gtk_size_group_remove_widget (GtkSizeGroup *size_group,
GtkWidget *widget);
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]