GNOME Smalltalk?

> Why don't the three of us all support each other in creating a GNOME/
> GTK+ IDE and community class library? I think it would be a great
> folly for each of us to re-invent the wheel.
>
> I think its quite clear (to me at least) that merging VM code is not
> going to happen. I am very attached to Panda, and Luca to Syx. So lets
> at least rectify the situation above the VM level. I think this is
> very doable, in the current technical and legal climate.
>
> I suggest creating a "GNOME Smalltalk" commons project which will
> consist of bindings for the entire GNOME stack, as well as a fancy
> development environment. We could put all sorts of other goodies in
> this project as well. The bindings FFI/API should more or less follow
> the GST's implementation (as it is the most advanced). The code would
> be kept in a neutral repository, under a license suitable to all three
> parties. I hope GST's copyright assignment still allows for retaining
> copyright for use in non-GST contexts. The code could possibly be
> licensed under the LGPL to allow crossbreeding with the strong GST
> libraries.
>
> There is this new tool in GNOME called gobject-introspection. Its
> primary aim is help create language bindings. For a long time in
> GNOME, language bindings were third-class citizens, as it was very
> hard and tedious to wrap GObjects. However, gobject-introspection
> makes things easier by allowing runtime introspection of GObjects,
> amongst other things. For instance, Colin Walters did a cool hack in
> which he generated GTK+ Java bindings at *run-time* using gobject-
> introspection (http://cgwalters.livejournal.com/19537.html).
>
> For GNOME Smalltalk to work, we will need to agree on the subset of
> our class libraries that need to be compatible with each other. I
> don't think this should be too hard.
>
> As I mentioned to Paolo, I am very interested in Vassili Bykov's
> Hopscotch IDE (http://gbracha.blogspot.com/). From what I have read of
> it, their rationale and usability principles seem to be very sound.
> With that in mind, I am certainly not keen on doing a straight port of
> the Squeak browsers to GTK+. I get irritated by the modality of the
> Squeak class browser. For instance, If I am editing a method, and want
> to quickly view another method, I have to cancel editing. Only being
> able to view one method at a time is also restrictive. Someone very
> aptly called it a "pinhole" style of browsing.
>
> PS: I called this hypothetical project "GNOME Smalltalk", but we can
> improve on the name if needed.