Hello,
I am new to Squeak, but I have questions about the current UI. I have seen there are some Pluggable*Spec and Pluggable*Morph classes and it looks to me that the intention is to have something like in Cincom VisualWorks with the specs and possible later a graphical UI builder that acts on it. I have made a little test app to see how it works with the spec objects, but here are now my questions:
What is the intention to have spec objects, when we write code anyway and we could also write code that generates the morphs directly ? What is the intention to have spec objects, when we have thousands of other morph classes and we are always In the situation that our spec classes are never complete ? What is the intention to have spec objects, when they are cover only a small protccol of the underlaying morph ?
Is the final goal to have only Pluggable*Morph and Pluggable*Spec and all other morphs are deleted in future ? If not, how should I use other morphs, where no spec class is available ?
Why is there no reasonable „ApplicationModel“ class like in VisualWorks, that knows its builder and has a standard protocol for opening and implementing spec methods ? I was really wondering initially that my window looked different, until I found the reason, that I need to subclass it from „Model“, because there is some magic method implemented that returns the window color. This is hidden functionality which is at wrong place, just my opinion :-)
Currently I look also more like a beginner on to the Morph hierarchy, so my understanding of it is very restricted, I come from VisualWorks. But how is it with a ValueHolder hierarchy ? Makes it sense or have the Morphs another functionality, that I currently does not know. For me the current Squeak UI looks more like Cincom ObjectStudio, where I describe the UI with code and where the values/aspects are read/written directly, which makes it complicated when one thing is updated and 10 other dependents needs refresh too. I assume in such a case I need to write code for the dependent updates. This must not be bad at all, I have gotten into the habit to write code like this:
action self do. self changedAction
changedAction self changed: #action. self updateDependentA. self updateDependentB
I think there is much unready and work-in-progress, e.g. DropButtons do not work for me, but I want to understand the big goal.
Regards Jörg