One note on the GUI situation of Pharo.

The situation of Pharo is pretty much the same situation for most programming languages. I am coming from python and the situation is pretty much the same but scaled up to the size of the python community which is huge. So instead like pharo of having 6 or 7 GUIs frameworks , Python has hundreds. I will say 4 are the most popular, pyQT which wraps QT (and its alternative pyside) , wxPython (wraps wxWidgets) , pyGTK (wraps GTK) and tkinter (wraps tk gui api) .

All of the above frameworks have tons of users so one thing that this shows us is that fragmentation is really beneficial to a community. The reason is simple,

GUI is so complex subject but there will never be one ring to rule them all. Many have tried, all of them have failed. ��

Pharo will follow and does follow a similar route. I am actually thinking of making my own GUI API since none seems to fit my needs or the way I like to work.��

In the end no generic solution will be able to beat a customized one. This is why we need fragmentation.��

On Thu, Feb 12, 2015 at 10:46 AM, Hilaire <hilaire@drgeo.eu> wrote:

Le 11/02/2015 23:28, Sebastian Heidbrink a ��crit :
> I honestly try to bring Pharo/Smalltalk to the crowd, but somhow I
> feel like the UI development removes all the productivity that one
> usually has with Smalltalk.

You are pretty right. For a small UI project, the UI development can be
high.
For a bigger project, where the UI part represent a small fraction of
the whole project, it is a different story as most of the development
will be out of the UI land and will benefit from the Pharo productivity.
This is what I experienced with DrGeo.

By the way, before Polymorph, the situation was even worst.
Did you look at the Polymorph example in the WidgetExamples class ?
There are good starter.

Hilaire

--
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu