Re: [Help-smalltalk]_Gtk+_bindings

[Paolo Bonzini]

> Well, you could always implement a tree in Tk - I'm
> sure somebody has ;).

Yes, but not as full of features as Gtk's.

> Is is so bad to have a widget that is not (yet)
> implemented for one of the underlying toolkits,
> though? It's not as if tree views are indispensible in
> UI design.

Well, they do help in a class browser :-)

> Well, the point of MBox was that I couldn't get
> BContainer to work properly. In fact, a lot of this
> discussion would be moot if the you could get the
> packer to work - then you could support both geometry
> management schemes natively under both toolkits.

BContainer is a hack.  Hopefully after Gtk bindings are written it will be
more usable.

Wasn't the packer removed in 2.0?
> Incidentally, which version of Gtk are you using?

I am using 2.2.0.

> Only because that type of layout is so strongly
> discouraged in Gtk, so it seems kind of ugly to force
> all windows to include one in our Gtk bindings.

This is not completely true (GtkFixed is discouraged, but you have GtkTable
and a placer geometry manager is not much different).  The abundance of
geometry managers is a good reason (but they are windowless so they only
consume 200 or so bytes per window, I think).

> GtkWindow
> \_GtkVBox
>   |_GtkPlacer
>     |_GtkVBox
>       |_ ... all the other widgets ...

This can be avoided by reparenting the placer under the VBox when the menu
is created.

> > mourn
> >     | save |
> >     save := gtk.
> >     gtk := key := nil.
> >     gtk unref
>
> You mean save unref in the last line, presumably.

Of course.

> I think this boils down to leaving them alone, and
> letting the Smalltalk garbage collector take care of
> it. Perhaps that's best.

Yes, that's it.  You actually can use the standard finalization scheme in
GNU Smalltalk.  I have it implemented for objects that are passed through
closures, but not for objects that are returned with #new; I am going to
download the Python bindings now.  I suspect that it will help to do some VM
work to allow customization of the way return values are passed back from C
to Smalltalk.

> Do we need to prevent unwary users from inadvertently
> calling destroy on their widgets?

Just give them enough rope to shoot themselves on their feet, and remember
not to unref the object when the CObject is finalized.

> Slightly unrelated question: will a CObject be cleaned
> up if its underlying C structure is freed? Presumably
> not.

Nope, you have a dangling pointer.

> What is going to happen to all the GtkObjects when the
> image is restarted? They're all CObjects, but they
> won't be valid Gtk widgets. Is that going to require
> rebuilding all of the windows from scratch?

Yes, of course, like with standard Blox.

Paolo