I spent some time reviewing GtkConstrain and GtkKennel

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

    - 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

   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

   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.



typedef enum {
} 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]