Nahuel Greco wrote:

>Other option is to add multi window capabilities to Squeak and write a good and
>boring widget library :)
>
With modules well under way, this doesn't seem like such a bad idea. If 
I understand you, you are implying a smalltalk widget set that mimics 
the behavior of GTK, both in user experience and the ability to read GTK 
window specs. The work (in man-hours) might be a lot. But it has a some 
advantages over doing it with bindings to GTK.

First, with the arrival of modules, it could be implemented as a simple 
add on module, without radical changes or extentions to Morphic. Put 
another way, it seems to lend itself the style of open source 
collaboration that has evolved in the Squeak community. If Andreas is 
correct about how difficult it would be to do real GTK bindings, than a 
real worry about doing such a project is that developing and maintaining 
GTK support would be tantamount to a fork in the code base, or at least 
in Morphic. Unless, that is, we were able to get a high level of 
cooperation and collaboration from SqueakC. And my sense is that the 
SqueakC guys believe a boringly typical widget set is not where their 
priorities lay (intentionally tendentious phrasing). In contrast, 
writing the widgets as a set of modules could require minimal 
cooperation from SqueakC without losing the enumerable benefits of their 
continuing labors.

Third, less coordination would be required among developers. Anyone who 
wanted to pitch in could pick a GTK widget that has not been copied, and 
write it. Like it or not, copying existing UI designs is the bedrock of 
many, perhaps most, successful open source projects, including GTK 
itself. Either the widget set behaves like GTK or it doesn't, either it 
reads third party GTK window specs or it doesn't. There would still be 
conflict among developers about the underlying design, but the more 
"religious" conflicts over UI design that would be avoided, since anyone 
who wishes that there was a GTK-like widget set for Squeak has implictly 
signed on to the UI design before they write a line of code.

Fourth, of course, is that it is all in smalltalk. If, in the end, you 
in fact have not really signed on to the design of the UI for a given 
widget, than you could subclass it. With real GTK bindings, you are more 
beholden to GTK's machinery, and subclassing a widget may require some C 
code.

Fifth, of course, you would not have to ask your users to install GTK 
libraries on a Mac or Win32 machine.