Re: [gtk-list] Flawed design?

[Tim Janik <timj gtk org>]

On Wed, 7 Jul 1999, Per Erik Stendahl wrote:

> 
> Hi.
> 
> The tutorial says that there are a bunch of dialogs
> that "derive" from GtkWindow (e g the ColorSelection
> dialog). Now I assume that "derive" in this context
> means the same as it does in regular objectoriented
> design, that is that a ColorSelection dialog IS-A
> Window. This implies that I should be able to use a
> ColorSelection dialog whereever I can use a GtkWindow
> or even a GtkContainer which is a ancestor of
> GtkWindow.
> 
> I find that this is not the case. I can add a widget
> to a container (via gtk_container_add) but I cannot
> do the same to a ColorSelection dialog which I
> should be able to do since it IS-A container.

this is due to the GtkWindow being a GtkBin container, i.e.
it can only have *one* child, and that child slot is already
occupied by the composite children of the color selection.
you cannot add more than one child to ordinary GtkWindows as
well.

> My point is that I think that the widget hierarchy
> is flawed. The ColorSelection dialog (and probably
> the other dialogs too - I haven't checked them)
> should not derive from GtkWindow. They should not
> even derive from GtkContainer. They should possibly
> derive from GtkWidget.

those dialogs need to derive from gtkcontainer (actually from h/v box
or bin at least) because they are *composite* widgets, i.e. they have
builtin children.
you are right though that derivation from gtkwindow is a design flaw,
since this way one can't incorporate the dialog into existing windows
(at least not whithout *gross* hackery ;).
unfortunately the implemntators of these composites probably weren't aware
of the problem (restriction) when they started out hacking; some of the
newer dialogs come without a gtkwindow though (e.g. the font selector).
of course, we do apprechiate patches to correct those flaws, the only problem
in this specific case is to preserve source compatibility.

regarding gtkwindow (actually you were referring to the colorselection,
but as you already figured, that is_a GtkWindow), yes you can't add it to
another container, eventhough it is derived from GtkWidget, and thus in
principle imlpements the concept of having a parent.
but you need to understand that we don't have totaly independant components
in a widget toolkit that you can stick together anyway
you want it (though, in comparision to other toolkits, gtk is pretty flexible
in that regard), i.e. we need to have a special objects that implement certain
concepts, like
- being a widget, i.e. implementing knowledge about gdk (X) windows and
  drawing oneself
- being a child, and getting managed by a parent,
- being a parent (container), maintaining children lists etc,
- managing other widget's layout (size allocation, resize handling)
- being a toplevel that is responsible for a complete widget tree (e.g.
  maintaining a focus or default widget), which cannot have a parent
  (otherwise it wouldn't be a toplevel anymore)

since gtk comes with a single inheritance tree, these things are (roughly)
implemented like this:

GtkWidget          - implements the concept of having a parent
  |                - implements the concepts of owning a GdkWindow
  |                  and being able to draw itself
  GtkContainer	   - implements the concept of being a parent,
    |              - managing the layout of its children
    GtkWindow      - imlpements the concept of a toplevel
                   * looses the ability to have a parent

with multiple inheritance you could have done something like:

                        GtkWidget  (GdkWindow, drawing)
                      /          \
                    /              \
      GtkChild (getting managed)   GtkContainer (managing children)
                                     |
                                   GtkWindow (toplevel, able to manage
                                              children, but doesn't have
                                              the "childhood" concept in its
                                              anchestry)

most gtk widgets would then derive from GtkChild *and* GtkContainer.

but as i said before, gtk supports only a single inheritance object
tree, so this is not even an option. the only alternative would have been

GtkWidget (GdkWindow, drawing)
  |
  GtkContainer (parentship)
  |  |
  |  GtkChild (childhood)
  |
  GtkWindow (toplevel without childhood)

but this is conceptually even worse, because a container needs to implement
certain knowledge about its children, and it would also mean that *all*
widgets besides GtkWindow, come with the overhead of a container
implementation, which is pretty useless for labels or pixmaps and the like ;)
  
> 
> There is a difference between "IS-A window" and
> "HAS-A window".
> 
> Regards,
> Per Erik Stendahl, CS student
> 

---
ciaoTJ