Towards a more flexible CMD+Dot ...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Towards a more flexible CMD+Dot ...

marcel.taeumel
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



cmd-dot-dialog.1.cs (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Towards a more flexible CMD+Dot ...

Chris Cunnington-4
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 <[hidden email]> 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>



Reply | Threaded
Open this post in threaded view
|

Re: Towards a more flexible CMD+Dot ...

marcel.taeumel
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 <[hidden email]>:

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 <[hidden email]> 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>



Reply | Threaded
Open this post in threaded view
|

Re: Towards a more flexible CMD+Dot ...

Chris Muller-3
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 <[hidden email]> 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 <[hidden email]>:
>
> 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 <[hidden email]> 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>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Towards a more flexible CMD+Dot ...

marcel.taeumel
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 <[hidden email]>:

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
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Towards a more flexible CMD+Dot ...

timrowledge


> On 2019-05-16, at 12:24 AM, Marcel Taeumel <[hidden email]> 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.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Bother" said Pooh, as his rucksack opened whilst skydiving



Reply | Threaded
Open this post in threaded view
|

Re: Towards a more flexible CMD+Dot ...

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

>
>
> > On 2019-05-16, at 12:24 AM, Marcel Taeumel <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Towards a more flexible CMD+Dot ...

Hannes Hirzel
In reply to this post by marcel.taeumel
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Towards a more flexible CMD+Dot ...

marcel.taeumel
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" <[hidden email]> 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