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@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui