OT - Squeak and the Broader Software Community

Hilaire Fernandes hilaire at ext.cri74.org
Sun Jul 9 10:46:24 UTC 2006



Rob Gayvert a écrit :
> Dan,
> 
> My 0.4 release was reasonably solid for Win32, but the Mac version
> wasn't as good (partly my fault, partly the state of wxMac 2.5), and the
> Linux version wasn't really usable. I'm hoping that the 0.5 release

I noted the Linux version is a bit slow (I cannot compare to the other
version).
Is it related to Squeak or is related to wxWidget?

At least in the Linux  version, AFAIK, with wxWidget you have two levels
of indirection:
 wxWidget <--> GTK+ <-->Xlib
It may also explain why it seems slow.

Nevertheless the wxWdiget is a far more complete set of widget than GTK+
 and it has quite a good native look and fell, which is quite important
for end users experience.

> (coming RSN) will work well on all three platforms.
> 
> As for all of the other discussion about wx/gtk/Spoon, I liked Cees'
> response the best: Why one UI? There are pros and cons to any UI
> toolkit, so the more options there are for Squeak, the more
> opportunities there will be to use it. My goal with wxSqueak has been to

Hum, in theory this is absolutely right. Practically what we have now is
zero reliable solution for a UI widgetery. I am not bashing on what you
and Bruno are doing, it is just to recall doing one thing right is just
more easy than doing two things right. Is it not common sense?

Adopting officially for squeak.org roadmap one widgetery, will
definitively help a lot to do this one right and reliable. Of course it
does not prevent for alternative widgetery.

Then we could wonder why those professional Smalltalk vendors does only
provide one set of widgetery. After all with their resources, they could
provide a set of different widgeteries. Oh but may be there are doing so.

How do fell other about getting one UI widgetery mainstream in Squeak.org?



>  keep it compatible with the latest release of Squeak, with minimal VM
> changes, and maybe eventually no VM changes at all. And ultimately, it
> should work fine with Spoon. But I think it should always be an add-on
> package to some Squeak/Spoon core.
> 
> .. Rob



More information about the Squeak-dev mailing list