GNU Smalltalk on OS X with native GTK

That was not as difficult as I had imagined.

1. install gtk-osx from http://www.gtk-osx.org/
2. install gawk from http://ftp.gnu.org/gnu/gawk/ - make sure the  
$BINDIR is in your PATH
3. Build and install pkg-config-0.23.tar from http://pkgconfig.freedesktop.org/releases/ 
  - again, put $BINDIR in your PATH
   export PKG_CONFIG_PATH=/Library/Frameworks/Cairo.framework/
Resources/dev/lib/pkgconfig:/Library/Frameworks/Gtk.framework/
Resources/dev/lib/pkgconfig:/Library/Frameworks/GLib.framework/
Resources/dev/lib/pkgconfig

4. build GNU Smalltalk:
   MAKE=gnumake CFLAGS='-m32' LDFLAGS='-arch i386' ./configure --
prefix=/usr/local/gst --enable-gtk=yes
   gnumake
   sudo gnumake install

Running gst-browser: http://gallery.me.com/eli.green#100171

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

Note that this is running under Quartz, the native OS X display  
server, but does not use the native theme. There is a Gtk engine which  
does so but I haven't tried to compile it yet.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

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.

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

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.

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.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

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

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.

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.



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Tue, 2009-10-13 at 01:11 +0200, Paolo Bonzini wrote:
The X11 version of GTK has not this bug this is specific to GTK-Quartz.

Yes there are some specific stuff on GTK-Os x for the menu bar and
the shortcuts

the theme : available in svn.gnome.org/svn/gtk-quartz-engine or
http://github.com/rcaelers/gtk-quartz-engine/tree

For the integration :
http://sourceforge.net/apps/trac/gtk-osx/wiki/Integrate

for example the menu bar :
  gtk_widget_hide (menubar);
  ige_mac_menu_set_menu_bar (GTK_MENU_SHELL (menubar));

For the shortcuts it seems that this can be done automatically :
Menu: Helps integrates the application's menus onto the Mac Menubar, move the About, Preference,
and Quit menu items to the Application menu, and mutate some of the keyboard shortcuts from Control-Foo to Command-Foo.



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 10/13/2009 09:54 AM, Gwenael Casaccio wrote:
> The X11 version of GTK has not this bug this is specific to GTK-Quartz.

So you can reproduce it under GTK-Quartz?

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Tue, 2009-10-13 at 10:03 +0200, Paolo Bonzini wrote:
> On 10/13/2009 09:54 AM, Gwenael Casaccio wrote:
> > The X11 version of GTK has not this bug this is specific to GTK-Quartz.
>
> So you can reproduce it under GTK-Quartz?
>
> Paolo

Reproduce not really but when I've played with GTK-Quartz
and SqueakGTK I had the same strange bugs and many other
but with the events loop (nothing was drawn on the screen).

For the Cocoa may be we can create a binding. I don't know
how much time it will take ...

Gwen



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

>>> The X11 version of GTK has not this bug this is specific to GTK-Quartz.
>>
>> So you can reproduce it under GTK-Quartz?
>
> Reproduce not really but when I've played with GTK-Quartz
> and SqueakGTK I had the same strange bugs and many other
> but with the events loop (nothing was drawn on the screen).

Fair enough.

> For the Cocoa may be we can create a binding. I don't know
> how much time it will take ...

Not much, but as usual it's a matter of priorities.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

 
On Tuesday, October 13, 2009, at 10:19AM, "Paolo Bonzini" <[hidden email]> wrote:
>
>> For the Cocoa may be we can create a binding. I don't know
>> how much time it will take ...
>
>Not much, but as usual it's a matter of priorities.
>

find . -name \*.st | xargs grep -c -i gtk | awk -F : 'BEGIN { total = 0; count = 0 } { total += 1; if ($2) count += 1 } END { print total, count }'

I think it would actually be a pretty serious effort. Running this in packages/visualgst shows me that 93 out of 142 smalltalk source files directly reference or are at least aware of Gtk stuff. That's a lot of refactoring. As much as I would love to have something very high level for doing GUI work that felt completely native on every platform, it's a holy grail that wxWidgets, Qt and others have been chasing for a long time.

Now, binding to Cocoa itself should be relatively simple: Objective-C is semantically very similar to Smalltalk, except for the difficult parts where it accepts raw C types as arguments to messages. I know the VisualWorks guys produced a subclass of Namespace that loaded Obj-C libraries transparently.

I would say that the sensible way to proceed would be to fake it with a mostly-native look and feel using what Gtk has already built.



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 10/13/2009 11:02 AM, Eli Green wrote:
>
> On Tuesday, October 13, 2009, at 10:19AM, "Paolo Bonzini"<[hidden email]>  wrote:
>>
>>> For the Cocoa may be we can create a binding. I don't know
>>> how much time it will take ...
>>
>> Not much, but as usual it's a matter of priorities.
>
> I think it would actually be a pretty serious effort. Running this in packages/visualgst shows
 > me that 93 out of 142 smalltalk source files directly reference or
are at least aware of Gtk stuff.
>
> Now, binding to Cocoa itself should be relatively simple

Yes, that's what I meant -- not using it in VisualGST.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk