Re: [Help-smalltalk] GNU Smalltalk on OS X with native GTK

[Eli Green]

On Oct 13, 2009, at 01:11, Paolo Bonzini wrote:

> On 10/13/2009 12:05 AM, Eli Green wrote:
> > It is not what I would call stable or even usable; a few windows that
> > don't draw themselves, a lot of spinning beach balls (the "Window  
> > is not
> > responding to events" indicator in OS  X).
>
> It would be interesting to know if the X11 version has the same  
> bugs, so as to pinpoint bugs or differences in GTK-Quartz.  It seems  
> usable to me under both X11 and Window, and GTK-Quartz is the most  
> experimental GTK backend.

When I first launch gst-browse, a window comes up and lays itself out  
but never gets to draw any widgets (although there are darker grey  
rectangles inside the window, so they have been created and attached  
to the window). It sits there with an error about not being able to  
read a file and doesn't respond until I send a break to the terminal -  
at which point everything comes to life and starts drawing itself. I  
don't actually notice any problems after that. I'm tempted to think  
that it may actually be a problem in the VM (I'm compiling against the  
HEAD or whatever it's called in the land of git) or some piece of code  
creating an infinite loop.

I'll take a closer look at the output and see if I can figure out  
where it's getting locked up.

> > From what I can see,
> > VisualGST is written directly against the Gtk libraries so it's not  
> > like
> > somebody could simply implement a Cocoa version of Blox or  
> > equivalent.
> > Has any thought been given to placing an abstraction library  
> > between GST
> > and the native platform libraries or is GTK going to be the solution
> > going forward?
>
> Native-themed GTK, plus maybe a simple wrapper for the GTK-on-Mac  
> libraries that fix the menu bar, is probably good enough.

The truth is you can get 90% of the way there with a bunch of platform- 
specific customizations. For example, Macs use Command, not Control,  
for most of their operations. Gtk doesn't realize this on its own.  
Mimicking the next-tab and previous-tab commands from Safari and  
Terminal would make people feel more at home as well.

Of course, a double-clickable "GNU Smalltalk.app" would really be  
snazzy but that's a minor point.

> Blox is good enough for simple things, but really implementing a  
> complete modern UI class library is too much.  If I was starting  
> from scratch, maybe it would make sense to reimplement Cocoa in  
> Smalltalk, but that would be an incredible amount of work.  This is  
> not to say Blox is bad---it used to be a small Xt wrapper and it has  
> been made into a wrapper for Tk and (partly) GTK+, so it turned out  
> to be way more flexible than it was meant to be.

I was imagining something like implementing the Smalltalk-80 MVC or  
Morphic in GST with platform-specific bindings. But you're right, even  
that is a major effort and the problem with very high level frameworks  
is that eventually you end up wanting access to something lower level.  
It would be pretty amazing to have a Smalltalk that spoke Cairo/Gtk on  
Linux and Cocoa/Quartz on Mac OS X but the path of least resistance is  
probably getting a cleaner, stabler version of Gtk for OS X.

Anyway, I'm more interested in working in Iliad than on GST itself but  
I'll see what I can do to make this a more attractive option on this  
particular OS.

> Thanks for the build recipe!  I didn't think it would be difficult,  
> just untested.  I had tested the various parts using the .pc files  
> from gtk-osx.org, but I had never done a full build.  Can you put it  
> in the wiki, or shall I?  Also, did you really need "--enable- 
> gtk=yes"?  It should be done automatically.

Oops. That was left over from an earlier attempt where I didn't  
install pkg-config but it's simply too much hassle without it. You're  
right - as long as pkg-config is in your path and set up properly, it  
works without that flag.

I also made an attempt to build an Xcode project for GST but it's a  
complicated enough build process that it wasn't obvious how to proceed.