Hmm... maybe this kind of feedback:

- Should it be a preference or the default way of CMD+Dot? - What entries would you like to see in this list by default? - How might a possible extension point look like to add a domain-specific clean-up rule? or is #cleanUp: enough?

Best, Marcel Am 15.05.2019 18:46:36 schrieb Chris Cunnington brasspen@gmail.com: This is interesting. I wanted to add a Load Abort button to ScriptBook, but I realized that you can’t press a button in the UI when something is loading. The only way to stop it is CMD+Dot. Initially I thought I’d have a button that did what CMD+Dot did, but for the life of me I couldn’t see how that worked. I’m glad to see it so clearly illustrated. As it works, I’m not sure what kind of feedback you’re looking for here. But if you’re polling to see if people think it’s a good idea, then you have my vote.  +1

Chris

On May 15, 2019, at 10:47 AM, Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:

Hi, there.

Please find attached a changeset. It represents a quick prototype to make the CMD+Dot command more powerful. One might extend it to provide user-friendly, domain-specific clean-up or restarts of applications.

<image.png>

Best, Marcel <cmd-dot-dialog.1.cs>

Hi Chris,

thanks for these suggestions. One major concern is to use *as little code as possible* like in the emergency evaluator. Let's see what's possible in this regard.

Best, Marcel Am 16.05.2019 00:26:22 schrieb Chris Muller asqueaker@gmail.com: Hi Marcel,

Great idea to improve the Interrupt! function. I would eschew a Boolean preference for a kind of "handler" that could be selected such as;

1) presents the menu you presented (or a custom menu), 2) traditional Smalltalk IDE behavior (no pre menu), 3) showing a list of processes to select and act on, 4) nothing, completely disabled (user production system), or 5) something customizable like #3 for production system, but also write a log file to disk or network for customer support..or maybe increment a counter for usage tracking (to answer the question, "how often are people feeling the need to interrupt"), etc.

• How might a possible extension point look like to add a domain-specific clean-up rule? or is #cleanUp: enough?

Another good idea of something to try to standardize on. Seems like multiple frameworks have #cleanUp:, doesn't it? A registry of some kind where apps can add which classes they want sent #cleanUp: whenever that menu item is selected (or event triggered) would be nice. Class-side #cleanUp:'s are good places, since they're the objects responsible for making instances in the first place. I definitely wouldn't recommend anything like enumerating class hierarchy and sending #cleanUp:, though. Only registered. Full control.

Best, Chris

On Wed, May 15, 2019 at 11:59 AM Marcel Taeumel wrote:

Hmm... maybe this kind of feedback:

• Should it be a preference or the default way of CMD+Dot?
• What entries would you like to see in this list by default?
• How might a possible extension point look like to add a domain-specific clean-up rule? or is #cleanUp: enough?

Best, Marcel

Am 15.05.2019 18:46:36 schrieb Chris Cunnington :

This is interesting. I wanted to add a Load Abort button to ScriptBook, but I realized that you can’t press a button in the UI when something is loading. The only way to stop it is CMD+Dot. Initially I thought I’d have a button that did what CMD+Dot did, but for the life of me I couldn’t see how that worked. I’m glad to see it so clearly illustrated. As it works, I’m not sure what kind of feedback you’re looking for here. But if you’re polling to see if people think it’s a good idea, then you have my vote. +1

Chris

On May 15, 2019, at 10:47 AM, Marcel Taeumel wrote:

Hi, there.

Please find attached a changeset. It represents a quick prototype to make the CMD+Dot command more powerful. One might extend it to provide user-friendly, domain-specific clean-up or restarts of applications.

Best, Marcel

On Thu, May 16, 2019 at 09:48:40AM -0700, tim Rowledge wrote:

...

On 2019-05-16, at 12:24 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:

Hi Chris,

thanks for these suggestions. One major concern is to use *as little code as possible* like in the emergency evaluator. Let's see what's possible in this regard.

Exactly; it needs to be as insulated from possible side-effects of other code as possible, as locked-down as practical and resilient enough to make the people that program the lowest levels of interplanetary probes feel proud.

Indeed, keeping it sufficiently minimal is a challenge.

The user interrupt handler is tricky business. Refreshing my memory from http://bugs.squeak.org/view.php?id=1041 the four tests that Andreas put forward for interrupt handling are:

"[true] whileTrue" "[[true] whileTrue] forkAt: Processor userSchedulingPriority + 1" "Smalltalk createStackOverflow" "[Smalltalk createStackOverflow] forkAt: Processor userSchedulingPriority + 1"

All of these are still working after loadling the change set, kudos!

I did find that the results seem confusing if I hit CMD-dot several times in a row before the menu appears. That is a common thing that happens when the user (e.g. me) thinks that the image is running away and not responding to the CMD-dot (easy to do on test #4 for example). Maybe there is something we can do to to make that better. But overall I think the user interrupt menu would make the system feel more comfortable for people encountering these problems for the first time.

Dave

Needs more time to figure out a good design. Not ready for 5.3, I suppose. Sorry. 🙂

On Fri, Aug 30, 2019 at 1:45 PM +0200, "H. Hirzel" <hannes.hirzel@gmail.commailto:hannes.hirzel@gmail.com> wrote:

Hi

It seems that the proposal for a cmd-dot with options has not been included in the trunk? Are there any reasons against including it?

Regards, Hannes

On 5/15/19, Marcel Taeumel wrote:

Hi, there.

Please find attached a changeset. It represents a quick prototype to make the CMD+Dot command more powerful. One might extend it to provide user-friendly, domain-specific clean-up or restarts of applications.

Best, Marcel