[squeak-dev] Replacing or enhancing or supplementing Morphic (was: How do I "sleep 5"?)

Benoit St-Jean bstjean at yahoo.com
Tue Feb 28 21:05:02 UTC 2023

What would you say didn't work well with Wrapper?  What would you 
change/fix now? And would you keep the old dependency mechanism or use 

On 2023-02-28 15:36, Stephen Travis Pope wrote:
> Hello Squeakers,
> My reasons for wishing Morphic gone are several:
> 1: the mixing of view and controller, which hinders reuse and multiple 
> viewing;
> 2: the poor factoring so that the base Morph class has 6 instance 
> variables and many of the most-used Morph classes (e.g., 
> PluggableListMorph, PluggableTextMorph) have 20 or more instance 
> variables, leading to poor garbage collection performance for complex 
> GUIs;
> 3: the thread-unsafe nature of Morphic, and
> 4: Morphic isn’t MVC and doesn’t use the dependency mechanism for 
> updating, leading to poor scalability and multiple viewing.
> Thank you, Marcel, for letting us know how you think we should 
> proceed, but I was hoping that this forum was for discussing 
> alternatives before a single individual starts coding a new system.
> I’d like to propose a system like the VisualWorks “Wrapper” framework 
> (which I admit to being co-author of [with David Leibs]), which has 
> several advantageous features:
> 1: GUIs are composed of nested very simple “wrapper” objects that 
> handle clipping, translation, scaling, etc. but are not themselves 
> display objects;
> 2: Display methods support bitmaps, graphic contexts or external 
> vector APIs as output media;
> 3: Models are wrapped in ApplicationModel classes making them more 
> pluggable and reusable via a set of AspectAdaptors and ValueHolders;
> 4: It has a comprehensive collection of widgets;
> 5: It has a drag’n’drop and forms-based GUI builder; and
> 6: It’s been in use since the late-1980s with only minor changes.
> Here’s some doc:
> preview.png
> cb25 <http://www.esug.org/data/Old/vw-tutorials/vw25/cb25.pdf>
> PDF Document · 2.3 MB 
> <http://www.esug.org/data/Old/vw-tutorials/vw25/cb25.pdf>
> <http://www.esug.org/data/Old/vw-tutorials/vw25/cb25.pdf>
> stp
> --------
> Stephen Travis Pope    Ojai,California, USA
> pastedGraphic.tiff
> http://HeavenEverywhere.com
> http://FASTLabInc.com
> https://vimeo.com/user19434036/videos
> http://heaveneverywhere.com/Reflections
>> On Feb 26, 2023, at 1:51 AM, Marcel Taeumel via Squeak-dev 
>> <squeak-dev at lists.squeakfoundation.org> wrote:
>> Hi all --
>> Here is how one would start such an endeavor:
>> 1. Begin with implementing your new GUI framework in a repository of 
>> your choice.
>> 2. Once it is usable and you have demonstrated that with some 
>> content, tell people about it on the list to find more contributors 
>> for your project.
>> 3. Once your GUI framework (and tools around it) is mature enough, 
>> advocate for being able to tell users in a fresh Squeak image about 
>> it and install it with a simple button click. We have done this for 
>> Git support, Refactoring tools, Squeak Inbox Talk, Auto completion, ...
>> After that --- projects rarely finish step 1 --- you could decide to 
>> hand over the entire project to Squeak by integrating it into the 
>> Trunk. Alternatively, one could offer special Squeak bundles that 
>> have our new GUI framework installed and ready to use. Yet, Step 3 is 
>> usually worth pursuing first.
>> Here is how NOT to do it:
>> - Starting some unfinished experiment and pushing it into Trunk, 
>> hoping that other people will take care of it.
>> - Having a mature version of your GUI framework in regular Trunk and 
>> still developing it in your personal repository.
>> At the end of the day, personal time is often spent more wisely in 
>> understanding and using and improving what is already there. Feel 
>> free to start your own libraries and applications, sure. But having 
>> the goal of replacing something that is already working is rarely a 
>> good idea. Definitely unwise for something as complex as a GUI framework.
>> Did you know that you can implement new widget libraries on top of 
>> Morphic?
>> - https://github.com/tom95/Pheno
>> - https://github.com/hpi-swa/widgets
>> That said, we should keep on cleaning up the system to improve 
>> modularity (by untangling dependencies) to be able to unload the 
>> things you do not need for your personal projects such as EToys, MVC, 
>> MorphicExtras, ... :-)
>> ***
>> What about Tweak? I think that Tweak has really good ideas in terms 
>> of event processing. Personally, I don't think that it is better than 
>> Morphic, just different. Yet, it would be nice to have a simple 
>> working version of it in Trunk, like we have with MVC. Squeak's 
>> project abstraction can handle that. Then people can more easily 
>> learn about it and we can preserve its ideas in executable form.
>> Best,
>> Marcel
>>> Am 25.02.2023 01:23:16 schrieb Jecel Assumpcao Jr <jecel at merlintec.com>:
>>> David T. Lewis wrote on Fri, 24 Feb 2023 17:48:30 -0500
>>> > On Thu, Feb 23, 2023 at 11:47:12PM -0500, Benoit St-Jean via 
>>> Squeak-dev wrote:
>>> > > Nothing prevents us from replacing Morphic or redesigning it!
>>> > >
>>> > > If Juan was able to do it for Cuis and Sam Shuster was able to 
>>> design
>>> > > Pollock for VW, what's stopping us from even considering that 
>>> option?
>>> > >
>>> >
>>> > There is absolutely nothing preventing someone from developing a
>>> > replacement for Morphic in Squeak. In fact, Squeak provides exactly
>>> > the tools needed to support this. The key concept is that we can have
>>> > different kinds of Project that can be defined and built up to support
>>> > entirely new and different user interface models. Currently we think
>>> > mainly of Morphic and MVC, but there is no reason at all that someone
>>> > could not build something new and different.
>>> An example of an alternative GUI was Andreas Raab's "Tweak", which was
>>> used in the Croquet and Sophie projects.
>>> http://wiki.squeak.org/squeak/3867
>>> https://en.wikipedia.org/wiki/Tweak_programming_environment
>>> I am not sure why this didn't become an option in the standard Squeak
>>> distribution.
>>> Another GUI for Squeak was PenSprites implemented at Disney. It was a
>>> fraction of the size of Morphic meant for resource constrained devices.
>>> That remained internal to Disney.
>>> About MVC and Morphic, you have to remember that Squeak was created to
>>> implement EToys. EToys projects can have several things active on the
>>> screen at the same time while MVC is about switching focus between
>>> objects on the screen as the user interacts with them. If you start a
>>> fish swimming in circles in one corner of the screen you don't want it
>>> to freeze up if you start a new drawing in another corner.
>>> -- Jecel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20230228/0033d110/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: preview.png
Type: image/png
Size: 42102 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20230228/0033d110/attachment-0001.png>

More information about the Squeak-dev mailing list