Re: [Help-smalltalk]_Gtk+_bindings

[Paolo Bonzini]

> 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).

> 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.

> 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?

> BContainer itself is something of a make-it-fit solution.

Yes, it is.

> 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.

> Can we provide pure-Gtk bindings as well as Blox-Gtk bindings in a
> reasonably elegant fashion?
>

> Yes, based on 2.4.6. It's an ARM processor, although off-hand, I can't
> tell you the exact flavour - there is a tool-chain for it already, with
> gcc version 2.95.2 (which might be the source of some of my trouble - I
> seem to remember there were issues with older versions of gcc before).

> At the moment, it's complaining about missing alloc.h, if that sounds
> familiar to you.

More likely.

> I can't actually work out whether it should be looking
> for it, though.

In libgst!

> I hadn't thought of making the Namespace a pool dictionary. Can you do
> that? I was trying to work out how pool dictionaries work just a few
> days ago. Can you make any Dictionary a pool dictionary, or does it have
> to be a specific type?

Yes, you can.  A pool dictionary is the place for imports.

> 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 will also need to ref/unref the object in the closure invocation
functions.  That means before Smalltalk is invoked.  I need to check out
whether Gtk does that in g_value_get_object or whatever it is called.

> The reservation is the number of bindings that are generated.

I know this.  But in the future there might be image packing through
elimination of unused selectors.

> Paolo, I've wasted far too much time thinking about this. If you want to
> convert anything to use the other bindings, you're more than welcome.
> For my part, I think I'm probably going to continue along the same lines
> for a while, although I'm certainly going to take some of that work on
> board - the signals / closures at the very least.

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

Here is the update on the blox-gtk directory.

Paolo

blox-gtk-update.tar.gz
Description: GNU Zip compressed data