Hi,

To answer some of the 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 ?

Squeak includes not only Morphic as a UI framework; it also includes
the MVC classes known from Smalltalk-80 (see the ST80 class category).
The ToolBuilder consumes specs and builds concrete widgets out of
them. For Morphic, the implementation is in MorphicToolBuilder, and
for MVC in MVCToolBuilder. Which is used depends on the kind of
project you are currently in (Morphic project or MVC project), so you
get the correct widgets for your current project without the need to
let the Model care about this difference as long as it sticks to using
the specs rather than the concrete widget classes.

> 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 ?

The intention is to be independent from the concrete project type, but
the drawback is the least common denominator problem with regards to
the feature set of the widgets. If people would introduce new kinds of
specs, I assume most would create only Morphic implementations and
extend the MorphicToolBuilder, but not MVC implementations and the
MVCToolBuilder accordingly.

> What is the intention to have spec objects, when they are cover only a small protccol of the underlaying morph ?

See above, plus the widgets built send messages to their model object
directly, not to the spec. So the spec does not have to know
everything that the model knows, see below.

> Is the final goal to have only Pluggable*Morph and Pluggable*Spec and all other morphs are deleted in future ?

No, the Pluggable*Morphs are just Morph implementations that are built
by the MorphicToolBuilder to satisfy the Pluggable*Specs.

> If not, how should I use other morphs, where no spec class is available ?

It is customary that the build methods of the Models and the
ToolBuilders answer the widget that they have built. If your program
will only ever run in a Morphic world, you can expect that the answer
will be some kind of Morph. So you can use the Morph protocol to add
any further Morphs you desire. To access inner widgets, you can give
specs a #name:, and after building send #widgetAt: to the ToolBuilder
instance to get back the widget that was built for a spec with the
given name.

If you do not need the abstraction of specs and the ToolBuilder, nor
the option of running your GUI in MVC without a separate
implementation, you can also just construct Morphs directly. No need
to use specs or ToolBuilder.

> [...] 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.

In the ToolBuilder setting everything still follows the
model-view-controller pattern even if the Morphs implement both view
and controller. The views/Morphs are supposed to observe their model
object for updates through the observer mechanism. In reaction to such
updates, the views/Morphs will send messages to the model to obtain
the new values for display. In the specs you can specify the selectors
of these messages (e. g. use spec color: #myColor to let the
view/Morph send #myColor to the model to retrieve the actual color),
also for the mutator messages formerly supposed to be sent by
controllers (e. g. spec setText: #label: to send #label: when text is
accepted in the Morph). In the model implementation (e. g. in the
label: method) you must update the state upon receiving such mutator
messages, and you must trigger an observer notification explicitly by
sending #changed: to the model with the selector of the property (e.
g. #myColor) as the argument. Otherwise the observers will not update
themselves.

> action
>      self do.
>      self changedAction
>
> changedAction
>     self changed: #action.
>     self updateDependentA.
>     self updateDependentB

The explicit invocation of #changed: is required if you want to update
the views (Morphs) for this model. But usually you do not need to
update dependents individually, as long as they are properly observing
the model object. You can add further observers with model
addDependent: newObserver if necessary. The ToolBuilder does that for
you for all the widgets it builds. The observers receive an #update:
message with the same argument as the #changed: message to the model.

Kind regards,
Jakob

Am Mo., 20. Dez. 2021 um 19:48 Uhr schrieb David T. Lewis <lewis at mail.msen.com>:
>
> Hello J??rg and welcome!
>
> The ui mailing list has been inactive for a number of years, so I am
> replying on the main squeak-dev list. Please join the squeak-dev list
> (http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-dev)
> and we can carry on the discussion there :-)
>
> I am not a good person to answer your questions below, but I will mention
> a couple of Squeak projects that may be of interest to you:
>
> hpi-widgets is a recntly developed library:
>
>   https://github.com/hpi-swa/widgets
>
> Bob Arning wrote a nice library that is described here:
>   http://wiki.squeak.org/squeak/1984
>   http://wiki.squeak.org/squeak/621
>
> The hpi-widgets library can be loaded following the instructions on
> its githubhome page. BobsUI can be installed through the SqueakMap
> Package Loader, which is one of the tools in the Squeak image
> (home -> open... -> SqueakMap Catalog). It has not been actively
> maintained, so it is likely to need some updates in today's Squeak.
>
> Dave
>
>
> On Sun, Dec 19, 2021 at 08:43:58AM +0100, J??rg Belger wrote:
> > 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
> > _______________________________________________
> > UI mailing list
> > UI at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/mailman/listinfo/ui
>