Jason,
Morphic's API certainly leaves room for improvement. My main interest in it is that it works and can get us to whatever we decide to do next. Given that, it seems reasonable to consider it as one of our view hierarchies of interest.
The more you describe what you want to do, the more I think about WindowBuilder. I appears to be alive and well via Instantiations and VA, but it should also live in Smalltalk Express. If we can get that to run, you will quickly get an idea of what it can do. The following might work (subject to AV checks, etc.):
http://www.smalltalk.org/versions/SmalltalkExpress.html
The patches probably refer to some changes to get it to run on "high" color depth video systems (aka, almost anything in use now<g>).
The "other" Dolphin-based generator I mentioned can be found here:
http://www.cjd77.com/smalltalk/PresenterGenTool.htm
I share your surprise at the way the rest of the world writes software. I could draw political analogies for it, but suffice it to say that I doubt the situation will change much. All of us found Smalltalk, and others will too, provided dialects continue to exist and remain viable.
Bill
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bschwab@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
jason.johnson.081@gmail.com 01/15/08 1:11 PM >>>
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. _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui