On Jan 14, 2008 9:23 PM, Bill Schwab BSchwab@anest.ufl.edu wrote:

Jason,

I probably did misunderstand you. Dolphin's ViewComposer does some of what you describe, but I suspect that Object Arts would be the first to agree that it could be done better. It might be interesting to look at WindowBuilder (if we can find a copy of Smalltalk Express or something else that has it and then get it to run), Dolphin Community Edition, and Squeak/Morphic.

I'm still go looking for documentation on Morphic from time to time to try to figure out what the advantage is. So far my impression is that it was a good idea from Self that just doesn't translate well to Smalltalk. And it sounds like the API is terrible.

I think the correct solution merges a code generator with a visual editor, the nature of which might change with the views (e.g. Morphic, wx, etc.). I have long done the code and view generator in a "batch" mode to generate GUIs based on various meta data sources.

At this point I'm not so big on generating views from "batch" mode, but the system I envision would be in pure Smalltalk so it wouldn't know or differentiate between receiving messages from code or from a designer application. I certainly wouldn't go out of my way to stop people from doing something they want to do.

There is a Dolphin solution that approaches it from the view, IIRC, generating code to match it. I should dig around for it and add it to our list of examples. Throw anything else you want in with it, stir, and plan a GUI editor. Is that closer?

Well, that's probably further then I had thought about at this point. I just noticed the C# ability to let one go very far in application development purely in the visual builder and think that would be nice to have in Smalltalk.

Of course there are times one needs extreme flexibility in building a system but the vast majority of applications don't require nearly that much work. When I look at the free software world around us one thing that sticks out to me is that these guys who do this in their precious spare time are writing their graphical applications in C (!!!). Why is that? Why wouldn't one use Smalltalk to slap together a GUI in a day?

I want to change that. I want to make a graphical building system that lets one build GUIs so fast that nearly everything in use on Linux could be duplicated in such a short time that the productivity can't be ignored. The Smalltalk and Lisp communities always talk about how much more productive we are (and I believe that), but we're not showing it.

BTW, just because I advocate against volatile changes to the language, please do not feel like we have to stick to ST-80. I would very much like to see Squeak more fully embrace exception handling, as well as provide shortcuts to avoid the overhead (such as using #at:ifAbsent: vs. having to catch errors from #at:).

I really like #ifAbsent: and use that pattern in my own code.

By "stock ST-80" I just meant not adding any language extensions. The libraries need to always be advancing. For example, Smalltalk has resumable exceptions. Having known about them from Lisp I thought that was good that they have them. But when one looks at how they look when used it leads to some pretty ugly hard to understand code. One thing I would like to explore at some point is adding Lisp-style restarts to Smalltalk so this would not only look better but be (imo) state of the art.

Squeak does it in some places and not others. If you want to call that "Smalltalk 95" or so, I'd let you get away with it. Dolphin and VW do some related things quite wel, and IMHO, Squeak should "learn" from them.

Agreed.