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.
_______________________________________________
help-smalltalk mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
