Re: [Help-smalltalk]_Gtk+_bindings

[MSA or SJF]

--- Paolo Bonzini <address@hidden> wrote:
> > I suppose my preferred approach would be to double
> up the widgets, and
> > provide a BTree as well.
> 
> Yes, mine too. (but this also implies kissing Tk
> goodbye).

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

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.

> > I'm not entirely against RSG - there are some
> tricks it can do that
> > boxes can't, and vice-versa. To each his own. It's
> simple enough to
> > implement a rubber-sheet widget using GtkLayout, I
> should think. Are you
> > suggesting emulating Gtk's geometry management
> when using Gtk as the
> > underlying widget set, though? That doesn't make
> sense to me.
> 
> I did write a simple GtkPlacer geometry manager
> based on the GtkFixed but
> with RSG.  I am suggesting emulating Tk's geometry
> management with a custom
> geometry manager, when using Gtk as the underlying
> widget set.  Then one can
> either use your MBox to re-emulate Gtk's geometry
> management (does not make
> much sense but it is cross-platform) or use
> BContainer which will use Gtk's
> boxes.

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.

Incidentally, which version of Gtk are you using?

> > If you go the Tk route, then you'll
> > be automatically adding a GtkLayout at the top
> level of every window,
> > which you might not think was so bad (I would, but
> that's beside the
> > point), but you're then going to have to
> incorporate menus into that
> > scheme.
> 
> Yes, you would have
> 
> GtkWindow
> \_GtkVBox
>   |_GtkMenu (or whatever it is called)
>   |_GtkPlacer
>      |_ ... all the other widgets ...
> 
> It would work but it is a bit messy.  I have zero
> experience with Gtk, so
> why would you consider adding a GtkPlacer in every
> place so bad?

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.

That's a relatively trivial point. From a technical
point of view, if you were going to use the Gtk
scheme, then you would most likely have:

GtkWindow
\_GtkVBox
  |_GtkMenuBar
  |_GtkPlacer
    |_GtkBox
      |_ ... all the other widgets ...

Which means that you have one redundant widget, and
two if the Box is a VBox. Well, I have a colleague who
constantly argues that this sort of thing is
inconsequential, but I also know that we've hit the
GDI resource limits under Windows, on account of using
too many window handles. Adding two extra widgets on
each window isn't going to threaten resources much - I
just have an aversion to it now. For a window without
a menu, I would *definitely* want to avoid this kind
of nastiness:

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

> > This is all personal taste, of course, but then,
> personal taste was what
> > drove me to look at the Gtk bindings rather than
> using the existing Tk
> > ones in the first place...
> 
> For me it was user's taste, not developer's taste. 
> Of course other's
> mileages may vary.

Ah, well, yes, but I spend much of my time doing
application programming, so really, I am more of a
user than a developer in this case :-)

> > The concern is memory (de-)allocation. I'm not
> actually sure if this is
> > a real problem in practice, but if a widget is
> freed, either you allow
> > Gtk to free all its children, and have some
> notification back to
> > Smalltalk, or you'd have to implement freeing them
> in Smalltalk.
> > Obviously, there is also the choice of simply
> leaving them alone, but it
> > seems to be a waste when there's quite a nice
> ref-counting scheme in
> > Gtk. Also, if you _ref the widget from Smalltalk,
> there's presumably a
> > possibility that Gtk will garbage collect it in
> the meantime. Actually,
> > that's a problem with an asynchronous event loop
> anyway, isn't it?
> 
> The idea would be to have a GtkHandle object that is
> an ephemeron.  It will
> also point to itself in the first field, like
> 
> gtkObject: gtkObj
>    key := self.
>    gtk := gtkObj.
>    gtk ref.
>    gtk sink
> 
> Then you receive a #mourn message in the GtkHandle
> when the first field
> (i.e. the handle itself) is not referenced anymore
> in the image: now do
> 
> mourn
>     | save |
>     save := gtk.
>     gtk := key := nil.
>     gtk unref

You mean save unref in the last line, presumably. I
think this boils down to leaving them alone, and
letting the Smalltalk garbage collector take care of
it. Perhaps that's best.

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

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

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?

> Let's just try to converge.  Sooner or later it will
> be easier to merge.

I'm all for that.

Sadly, I'm back at work (running late as I type), and
once again, there's precious little time to hack.

> Here is the update on the blox-gtk directory.

Thanks.


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com