[squeak-dev] Replacing or enhancing or supplementing Morphic (was: How do I "sleep 5"?)
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
> 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
> 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:
> cb25 <http://www.esug.org/data/Old/vw-tutorials/vw25/cb25.pdf>
> PDF Document · 2.3 MB
> Stephen Travis Pope Ojai,California, USA
>> 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
>> - 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.
>>> 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
>>> > > Pollock for VW, what's stopping us from even considering that
>>> > >
>>> > 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.
>>> I am not sure why this didn't become an option in the standard Squeak
>>> 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...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 42102 bytes
Desc: not available
More information about the Squeak-dev