Hi Benoît --

[...] I never seriously considered replacing Morphic altogether but we must at least recognize that Morphic could get a bit cleaner. [...] [...] Why can't we even *suggest* such a thing in Squeak without being attacked on the mailing list? [...]

What you might have experienced is a simple defense mechanism. ;-) You cannot expect the active community to be happy about you suggesting that nothing has happened in the past 10 years or so.

Some of us have the time and energy to keep on cleaning up and improving Squeak on a daily basis. We know about the dark and dusty corners. There is no "magic wand" but only hard work to be done.

Many onward decisions are not easy to be made and *require* people to stick around and stand behind them. One cannot just come along, yell around, delete some classes, and then disappear again.

Squeak's community and its ecosystem depend on honest contributions. At best, contributors have their own pet projects that motivate them to keep going and really figure out what's needed and what is not. And they are also able to realize when some area is just not their level of expertise to make substantial suggestions or improvements. Still, they should be encouraged to raise their concerns from time to time.

This is Morphic and *so* cool: http://www.zogotounga.net/comp/squeak/rogue.htm

[...] The 6.0 Squeak image I'm looking at right now has *** 512 ** Morph subclasses ! Do we need all that stuff? [...] Have you tried unloading EToys just for the fun of it?  It should be a one click or a one-liner thing but it needs its own page of instructions on the wiki [...]

Of course, we are also working on untangling the dependencies between EToys and the base system. Along the way, interesting ideas get even ported to become part of the base system.

I may be wrong, but to me, it looks like that you are either looking for or claim to have a "magic wand" that can make huge changes in a short amount of time without leaving people and content (!) behind.

https://raw.githubusercontent.com/squeak-smalltalk/squeak-app/squeak-trunk/r... https://raw.githubusercontent.com/squeak-smalltalk/squeak-app/squeak-trunk/r... https://raw.githubusercontent.com/squeak-smalltalk/squeak-app/squeak-trunk/r... https://raw.githubusercontent.com/squeak-smalltalk/squeak-app/squeak-trunk/r...

I get the idea of "basic Squeak" versus "Squeak with EVERYTHING it has to offer" but from a user perspective, [...]

Well, you are obviously having a kind of narrow perspective here. A Squeak bundle has far from "everything" loaded in the beginning. You might have a personal bias towards not liking EToys or some other content in the system. Then you come up with an argument like "512 Morph subclasses is too many". However, that's besides the point and not helping to clean-up the system. It's not that users are confronted with that number all the time -- tools will usually only show a fraction of that. Fixating an argument on arbitrary metrics overshadows the actual challenge: what *is* there actually and do we need it? Furthermore: do *I* need it or can I simply unload it for my personal project.

Yes, we know about all these things. And we have been working on that for many years. You are not mentioning new facts here... even though your words are more evocative compared to what is usually discussed on the list.

[...] One could hear the complaints against Morphic from Cuis & Pharo and honestly recognize that there is/was a problem. [...]

My personal guess would be that those communities have a fundamentally different perspective on what a Smalltalk system should be. There are voices that want to "dumb it down" (yes, not simplification but ignorance) by treating such systems as mere IDEs or by focusing on "programming language + standard library". However, I think that Smalltalk systems can shine when treated as being more like operating systems, rich multimedia environments, ...hmm... something malleable that might actually be able to "augmenting human intellect" (-> Doug Engelbart). It's more about a healthy environment with liveness and for exploration.

No, I don't think that we should grow a bigger community at all cost, following some fancy (short-living!) trends from other communities... Instead, we should look out for honest and long-lasting contributors that have real interest in understanding what is there and how to evolve it.

This here might be an interesting read and worth your time: https://dl.acm.org/doi/10.1145/3563835.3568733

For example, a community that disables the Morphic Halo feature by default does not understand or appreciate the benefits of direct manipulation at all. Here is a simple exercise: instead of picking out things that you do not like, try to make a list of things you do like (about Squeak). And then reflect again and discern "better" (or "worse") from "just different" to counter your personal learning bias.

I think we can say goodbye to portability. Backwards compatibility (from one Squeak version to another) is a totally different thing though.

There are several projects that are still portable because they mostly rely on fundamental Smalltalk concepts and standard interfaces such as Collections, Streams, Exceptions, and Tests:

- https://github.com/theseion/Fuel (Max is awesome!!) - https://github.com/Metacello/metacello - https://github.com/dalehenrich/filetree - https://github.com/hpi-swa/smalltalkCI - https://github.com/pharo-vcs/tonel   (kind of via: https://github.com/squeak-smalltalk/squeak-tonel) - https://github.com/svenvc/ston   (kind of via: https://github.com/squeak-smalltalk/squeak-ston) - ...

Therefore, I think that portability should have its place in a serious discussion about moving forward. :-) We must consider "Smalltalk as a whole" when looking for its place in the modern computing world.

Best, Marcel Am 24.02.2023 17:35:18 schrieb Benoit St-Jean bstjean@yahoo.com:

On 2023-02-24 04:02, Marcel Taeumel via Squeak-dev wrote:

Well, common sense does. ;-) Unless we make this a serious discussion considering Pros and Cons, such hasty thoughts will get us nowhere. From what I have read so far, I assume, that you have no substantial experience in writing Morphic applications? I don't know. Sorry, if my conclusion offended you. Your kind of shallow call just triggered something... :-/ Perhaps I wasn't/precise clear enough : I never seriously considered replacing Morphic altogether but we must at least recognize that Morphic could get a bit cleaner.  And the Squeak image too! The 6.0 Squeak image I'm looking at right now has *** 512 ** Morph subclasses ! Do we need all that stuff? I guess not. If at least we could unload packages in a *clean* manner, it would make things easier for everyone and facilitate building smaller runtime images.

I get the idea of "basic Squeak" versus "Squeak with EVERYTHING it has to offer" but from a user perspective, having 512 subclasses of Morph can be overwhelming.  On the other hand, if it's not in the image, how can a user easily find that a particular morph is available and exists in a certain repository/package? If Squeak comes loaded with EVERYTHING in the image, we should at least provide an *easy* way to unload what we don't need/want/use : that's not the case right now. Have you tried unloading EToys just for the fun of it?  It should be a one click or a one-liner thing but it needs its own page of instructions on the wiki (https://wiki.squeak.org/squeak/2848 [https://wiki.squeak.org/squeak/2848]). One could hear the complaints against Morphic from Cuis & Pharo and honestly recognize that there is/was a problem.  Why can't we even *suggest* such a thing in Squeak without being attacked on the mailing list?

And no, I'm not offended and your conclusion/assumption was right: my Morphic experience is limited

Maybe because us frequent users of Squeak/Morphic have already realized that both Cuis and Pollock are just different and not inherently better? Well, I don't know about Pollock. Cuis has different goals, backwards compatibility may not be among its most important ones.

I think we can say goodbye to portability. Backwards compatibility (from one Squeak version to another) is a totally different thing though.

It's not that difficult to come up with something different. The first weeks might be even fun. After that, you figure out all the corner cases and start arguing about compatibility and finding balance within the existing community. It is hard work. It is easy to ignore this fact in the beginning.

Best, Marcel Am 24.02.2023 05:47:30 schrieb Benoit St-Jean via Squeak-dev squeak-dev@lists.squeakfoundation.org [mailto:squeak-dev@lists.squeakfoundation.org]: 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?

On 2023-02-23 20:14, Stephen Travis Pope wrote:

Sounds like yet another reason to drop morphic, if you ask me, and go back to good-old MVC…

stp

--------

Stephen Travis Pope    Ojai, California, USA      [pastedGraphic.tiff]      http://HeavenEverywhere.com [http://HeavenEverywhere.com]      http://FASTLabInc.com [http://FASTLabInc.com]      https://vimeo.com/user19434036/videos [https://vimeo.com/user19434036/videos]      http://heaveneverywhere.com/Reflections [http://heaveneverywhere.com/Reflections]

On Feb 23, 2023, at 1:54 PM, Vanessa Freudenberg vanessa@codefrau.net [mailto:vanessa@codefrau.net] wrote:

Because Morphic is not multi-thread-clean, you have to be really careful how to write the do_something to be reliably executed from a different process. You have to coordinate with the UI process. In which case it actually becomes simpler to just stay in the UI process and use the mechanisms available.

Vanessa

On Thu, Feb 23, 2023 at 11:38 AM Stephen Travis Pope <stephen@heaveneverywhere.com [mailto:stephen@heaveneverywhere.com]> wrote:

I’ve been watching this thread and wondering why nobody suggests the simplest answer:

[(Delay forSeconds: 5) wait. do_something] fork.

stp

--------

Stephen Travis Pope    Ojai, California, USA     <pastedGraphic.tiff>      http://HeavenEverywhere.com [http://heaveneverywhere.com/]      http://FASTLabInc.com [http://fastlabinc.com/]      https://vimeo.com/user19434036/videos [https://vimeo.com/user19434036/videos]      http://heaveneverywhere.com/Reflections [http://heaveneverywhere.com/Reflections]

On Feb 22, 2023, at 11:16 AM, karl ramberg <karlramberg@gmail.com [mailto:karlramberg@gmail.com]> wrote:

On Wed, Feb 22, 2023 at 8:47 AM Taeumel, Marcel via Squeak-dev <squeak-dev@lists.squeakfoundation.org [mailto:squeak-dev@lists.squeakfoundation.org]> wrote:

(bm2 future: 1000) doButtonAction.

Also works for objects that are not or cannot be in the world.

Uses Morphic alarms when when in UI process.   Ah, that's cool. I never used #future:  :-)

Best, Karl

Best, Marcel From: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org]> on behalf of Eduardo Ochs <eduardoochs@gmail.com [mailto:eduardoochs@gmail.com]> Sent: Wednesday, February 22, 2023 7:17:01 AM To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org [mailto:squeak-dev@lists.squeakfoundation.org]> Subject: Re: [squeak-dev] How do I "sleep 5"?   Hi Karl! Fantastic, thanks! =) I added this to the class in which I'm putting most of my stuff,

!See class methodsFor: 'as yet unclassified' stamp: 'Edrx 2/22/2023 02:54'! run: aBlock after: ms | aButton | aButton := SimpleButtonMorph new. aButton openInWorld;         hide;         target: aBlock;         actionSelector: #value;         addAlarm: #doButtonAction after: ms. ! !

and now I can simply run this

See run: [ kf := self currentHand keyboardFocus ] after: 5000.

to save into the variable kf the morph on which the keyboard focus is after 5 seconds. Neat! =)

Cheers,     Eduardo Ochs     http://anggtwu.net/eev-squeak.html [http://anggtwu.net/eev-squeak.html]

On Wed, 22 Feb 2023 at 01:56, karl ramberg <karlramberg@gmail.com [mailto:karlramberg@gmail.com]> wrote:

Hi, A morph has to be in the world to be able to interact with it; eg. #openInWorld.

If you don't want to see the morph you can send it message #hide. It makes the morph invisible but it's still in the world and can interact with it.

To see the morph again send #show. To delete the morph send #delete. The morph will be garbage collected.

Best, Karl

On Tue, Feb 21, 2023 at 11:57 PM Eduardo Ochs <eduardoochs@gmail.com [mailto:eduardoochs@gmail.com]> wrote:

Hi Vanessa! Thanks! =) This works in a workspace,

"Create a SimpleSwitchMorph with label 'Toggle'       and a SimpleButtonMorph with label 'Flash'.       The button will be placed below the switch."     sm := SimpleSwitchMorph new.   sm openInWorld.   bm := SimpleButtonMorph new.   bm openInWorld.   bm position: bm position + (0@32).     "Three ways of toggling the color of the switch:"     sm toggleState.     bl := [ sm toggleState ].   bl value.     bm target: bl.   bm actionSelector: #value.   bm doButtonAction.     "Two ways of toggling the switch after 1000ms:"     sm addAlarm: #toggleState after: 1000.   bm addAlarm: #doButtonAction after: 1000.

but this doesn't:

bm2 := SimpleButtonMorph new.   bm2 target: bl.   bm2 actionSelector: #value.   bm2 addAlarm: #doButtonAction after: 1000.

What is the right way to add an alarm to a morph that is not shown on the screen? Also, can I create a new invisible morph every time that I want to run an alarm? Are they going to be garbage collected?

Thanks in advance!     Eduardo Ochs     http://anggtwu.net/eev-squeak.html [http://anggtwu.net/eev-squeak.html]

On Tue, 21 Feb 2023 at 02:16, Vanessa Freudenberg <vanessa@codefrau.net [mailto:vanessa@codefrau.net]> wrote:

The best way to do this in Morphic is with "alarms":

self addAlarm: #changeKeyboardFocus after: 5000.

which would execute the morph's changeKeyboardFocus method 5 seconds later.

The way of sleeping you suggest is possible too but more tricky, since you would have to move your wait code to an extra process to not block the UI process, but then make sure that the actual work is done in the UI process again (Morphic is not multithreaded, although Squeak is).

Vanessa

On Mon, Feb 20, 2023 at 8:49 PM Eduardo Ochs <eduardoochs@gmail.com [mailto:eduardoochs@gmail.com]> wrote:

Hi list,

a few days ago I asked for help on how to send a "synthetic" keyboard event to a morph, and Karl Ramberg gave me exactly the right hints in this thread:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2023-February/223473.... [http://lists.squeakfoundation.org/pipermail/squeak-dev/2023-February/223473....]

My code is ready except for documentation and comments - I'll work on that in the next few days and then post the result here and on the wiki...

...but there's a feature that I want to add to it that - again =( - needs something that I'm not being able to discover by myself. How do I write a line of code that waits for 5 seconds, sort of like running "sleep 5" in a shell, and that doesn't block the rest of the system? If I have that I'll be able to run these two lines in a workspace,

self mySleep: 5000.   kf := self currentHand keyboardFocus.

switch the keyboard focus to something else by clicking on it, and then the variable kf will be set to this "something else"...

Thanks in advance!   Eduardo Ochs   http://anggtwu.net/eev-squeak.html [http://anggtwu.net/eev-squeak.html]