Hi Marcel,
especially for this one tiny little thing of a modal alert when renaming classes?
It is a more general issue. There should be no UI invocation code in a non-UI part of the system. So, "Transcript showln:." is fine but "self inform:" is not. Why? Because those cannot be trapped in scripts, which is
- for example - unfortunate in automated pipelines such as our CI.
Actually, they can.
"example 1" [ self inform: 'stop everything and pay attention to me!' ] on: ProvideAnswerNotification do: [ : noti | noti resume ] "nil"
"example 2" [UIManager default request: 'what is the answer?' initialAnswer: 'tell me now!' ] on: ProvideAnswerNotification do: [ : noti | noti resume: 42 ] "42 "
I assumed this is what the CI jobs were doing.. they're not?
I totally share your sentiments about no UI invocation code in the domain, and is how I do my own designs, of course, but Squeak chose default to being an <<interactive system>>, and requires handlers of ProvideAnswerNotification to make it non-interactive, rather than the other way around.
If you want to flip the above in 5.4 to the normal way -- signaling a kind of ProvideAnswerNotification whose defaultAction issues the modal popup -- then let's flip them, but it doesn't seem like we need a new layer of notification classes just yet. ProvideAnswerNotification may be sufficient.
Best, Chris
What happened to simply opening up a MessageSet on the references
afterward?
Still there. Unrelated to this issue. See the end of Browser >> #renameClass.
Say, why do we need a modal alert at all?
I agree, that extra check in Class >> #rename: might not be necessary and maybe moved to our refactoring tools.
Best, Marcel
Am 26.02.2020 00:21:48 schrieb Chris Muller asqueaker@gmail.com: -1. "Notice" is such a generic, common word to steal from all applications that might want to create their own, especially for this one tiny little thing of a modal alert when renaming classes? Say, why do we need a modal alert at all? What happened to simply opening up a MessageSet on the references afterward?
- Chris
On Tue, Feb 25, 2020 at 8:17 AM Marcel Taeumel marcel.taeumel@hpi.de wrote:
Just "Notice"?
Am 25.02.2020 12:11:33 schrieb Eliot Miranda eliot.miranda@gmail.com:
On Feb 25, 2020, at 1:40 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Fixed. BUT: Please take a look at
Kernel-mt.1305 Tools-mt.941
We need a name! :-)
On second thoughts Notice might be a better name.
Best, Marcel
Am 25.02.2020 10:11:22 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Maybe it is a sporadic issue?
It is! Related to the ProgressNotification which I accidentially catch in Browser >> #renameClass. I wanted to get the UI call out of Class >> #rename:.
That progress notification does not appear every time. Only above a certain threshold. That's why it appears to be sporadic.
Best, Marcel
Am 25.02.2020 09:37:13 schrieb Thiede, Christoph < christoph.thiede@student.hpi.uni-potsdam.de>:
I could reproduce it one single time ... Maybe it is a sporadic issue?
Best,
Christoph
http://www.hpi.de/
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel *Gesendet:* Dienstag, 25. Februar 2020 09:34:03 *An:* John Pfersich via Squeak-dev; Chris Muller *Betreff:* Re: [squeak-dev] 5.3 cannot rename subclasses of Error
Hmm... I can reproduce the bug. Yet, calling "Error2 rename: #Error1" from a workspace works fine. Strange.
Best, Marcel
Am 25.02.2020 09:16:13 schrieb Thiede, Christoph < christoph.thiede@student.hpi.uni-potsdam.de>:
Hi Chris,
in a fresh image, I cannot reproduce this. Are you sure the class has not been renamed or is it possible that the class list was not updated properly?
Best,
Christoph
http://www.hpi.de/
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Chris Muller asqueaker@gmail.com *Gesendet:* Dienstag, 25. Februar 2020 06:29:00 *An:* squeak dev *Betreff:* [squeak-dev] 5.3 cannot rename subclasses of Error
In trunk / 5.3 RC.
- Make a subclass of Error called MyError1
- Make a subclass of Error called MyError2
- Delete MyError1
- Try to rename MyError2 to MyError1
The last step fails. No errors or debuggers, but the class is not renamed.
Works in 5.2.
HI,
Unless there is a good reason why handling ProvideAnswerNotification is not a good idea in scripted environments, I agree with Chris. I would prefer using the existing mechanism to introducing a strange synonym for Notification.
Swapping the control flow, like Christoph proposed (user code signals the notification and defaultAction is the modal dialog), sounds ok to me too. It would also mean that user code does not have to access the UIManager singleton. On the other hand, it is less obvious whether something is meant to be a UI interaction if the names of the Notifications make the code strange to read. For the most basic cases, at least there still is Object>>inform:/confirm:/confirm:orCancel:.
Kind regards, Jakob
Am Mi., 26. Feb. 2020 um 22:41 Uhr schrieb Chris Muller asqueaker@gmail.com:
Hi Marcel,
especially for this one tiny little thing of a modal alert when renaming classes?
It is a more general issue. There should be no UI invocation code in a non-UI part of the system. So, "Transcript showln:." is fine but "self inform:" is not. Why? Because those cannot be trapped in scripts, which is - for example - unfortunate in automated pipelines such as our CI.
Actually, they can.
"example 1" [ self inform: 'stop everything and pay attention to me!' ] on: ProvideAnswerNotification do: [ : noti | noti resume ] "nil" "example 2" [UIManager default request: 'what is the answer?' initialAnswer: 'tell me now!' ] on: ProvideAnswerNotification do: [ : noti | noti resume: 42 ] "42 "I assumed this is what the CI jobs were doing.. they're not?
I totally share your sentiments about no UI invocation code in the domain, and is how I do my own designs, of course, but Squeak chose default to being an <<interactive system>>, and requires handlers of ProvideAnswerNotification to make it non-interactive, rather than the other way around.
If you want to flip the above in 5.4 to the normal way -- signaling a kind of ProvideAnswerNotification whose defaultAction issues the modal popup -- then let's flip them, but it doesn't seem like we need a new layer of notification classes just yet. ProvideAnswerNotification may be sufficient.
Best, Chris
What happened to simply opening up a MessageSet on the references afterward?
Still there. Unrelated to this issue. See the end of Browser >> #renameClass.
Say, why do we need a modal alert at all?
I agree, that extra check in Class >> #rename: might not be necessary and maybe moved to our refactoring tools.
Best, Marcel
Am 26.02.2020 00:21:48 schrieb Chris Muller asqueaker@gmail.com:
-1. "Notice" is such a generic, common word to steal from all applications that might want to create their own, especially for this one tiny little thing of a modal alert when renaming classes? Say, why do we need a modal alert at all? What happened to simply opening up a MessageSet on the references afterward?
- Chris
On Tue, Feb 25, 2020 at 8:17 AM Marcel Taeumel marcel.taeumel@hpi.de wrote:
Just "Notice"?
Am 25.02.2020 12:11:33 schrieb Eliot Miranda eliot.miranda@gmail.com:
On Feb 25, 2020, at 1:40 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Fixed. BUT: Please take a look at
Kernel-mt.1305 Tools-mt.941
We need a name! :-)
On second thoughts Notice might be a better name.
Best, Marcel
Am 25.02.2020 10:11:22 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Maybe it is a sporadic issue?
It is! Related to the ProgressNotification which I accidentially catch in Browser >> #renameClass. I wanted to get the UI call out of Class >> #rename:.
That progress notification does not appear every time. Only above a certain threshold. That's why it appears to be sporadic.
Best, Marcel
Am 25.02.2020 09:37:13 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
I could reproduce it one single time ... Maybe it is a sporadic issue?
Best,
Christoph
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 25. Februar 2020 09:34:03 An: John Pfersich via Squeak-dev; Chris Muller Betreff: Re: [squeak-dev] 5.3 cannot rename subclasses of Error
Hmm... I can reproduce the bug. Yet, calling "Error2 rename: #Error1" from a workspace works fine. Strange.
Best, Marcel
Am 25.02.2020 09:16:13 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Chris,
in a fresh image, I cannot reproduce this. Are you sure the class has not been renamed or is it possible that the class list was not updated properly?
Best,
Christoph
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Chris Muller asqueaker@gmail.com Gesendet: Dienstag, 25. Februar 2020 06:29:00 An: squeak dev Betreff: [squeak-dev] 5.3 cannot rename subclasses of Error
In trunk / 5.3 RC.
- Make a subclass of Error called MyError1
- Make a subclass of Error called MyError2
- Delete MyError1
- Try to rename MyError2 to MyError1
The last step fails. No errors or debuggers, but the class is not renamed.
Works in 5.2.
Thinking about names and usage...
UserRequest (base class) "Christoph proposed UserNotification, but notifications can be dismissed easily, confirmations or choices should not be" "Also Monticello and other packages already use *Request for the purpose" InputRequest "accurate, but too general?" Request "probably too general" "contrast with WebRequest, for example" "asynchronous/continuation style:" (InputRequestSubclass signal) eventually: [:response | ... ]; then: [:response | ...]; ifRejected:/ifCancelled: [...]. "handling:" on: InputRequest do: [:request | request resume:/provide:/answer:/reply:/respond: whatever].
UserInformation signalWith: 'Looks ok' "remains open whether this will be a modal popup or a message in some kind of notification area" on: UserInformation do: [:info | info resume/dismiss/accept/continue "ok"] "but it might also be information about (not for) a user" UserNotification signalWith: 'This makes more sense to me here for inform:'. "This is not really a request for information, only for acknowledgement"
UserConfirmation signal .... "strange because here we want to request confirmation, not give one" UserConfirmation request: 'Does this look better?' "but signal is still inherited" on: UserConfirmation do: [:confirm | "strange again because the confirmation is yet to be given or denied"] UserConfirmRequest signal: 'This looks wordy even though it is already abbreviated' UserConfirmRequest request: 'Double double words'. UserConfirmRequest confirm: 'Double double, and the request shall confirm something??' "can be circumvented with a UserConfirmation factory but then signalling and handling use different class names" ConfirmationRequest signal: 'More letters, but looks nicer to me' trueChoice: #Agreed falseChoice: #Disagreed. on: ConfirmationRequest do: [:request | request resume:/respond:/reply:/answer:/choose: #Agreeable]. on: ConfirmationRequest do: [:request | request confirm/deny]. "ConfirmationRequested also possible, but not a noun -- different style"
MultipleChoiceRequest signal: 'I think it is...' choices: #(Good Bad Done) labels: #(Yay Nay What) "unfortunately the class name is already taken in RefactoringTools" ChoiceRequest signal: 'shorter but maybe stranger?' choices: #(Yep Nope) MultiResponseRequest signal: 'I like...' responses: #(Cats Dogs Squeak You) "funnily the term 'multiple choice' implies a single answer from a set of many" ConfirmationRequest "or others (see above) could also be a subclass of multiple choice" ClassOrTraitRequest signal: 'Choose your request'. (ClassOrTraitRequest fromPattern: '*Class*Request') signal: 'Other ideas?' ClassifierRequest signal: 'Do you prefer UML-speak?' DirectoryRequest signal: 'What kinds of other requests to/from/by/with/... a directory are there?' DirectoryRequested signal: 'This might be less ambiguous' File/Font/String/Text/Password/Credentials/ObjectRequest/ed signal: 'Likewise' initialAnswer: whatever. "Makes me wonder whether UserRequest might imply that a user must be chosen instead of requesting something from users" XyzRequestedFromUser signal: 'More explicit purpose, but yet another naming style' "Can there be a protocol to request a certain kind of object from the user or would we really need one subclass for each kind?" Xyz requestFromUser: 'Choose your Xyz...'. on: Xyz input/userRequest do: [:request | ...]. InputRequest signal: 'Choose your object' ofKind: Xyz. on: InputRequest do: [:request | (request acceptsA/n: Xyz) ifTrue: [...] ifFalse: [request pass]]. ...
There is also ProgressInitiationException which does not have a nice name. It is not a request, but it already has displayProgress:* in UIManager as defaultAction. Alternative names: ProgressInitiation/ed ProgressStart/ed
Am Fr., 28. Feb. 2020 um 22:11 Uhr schrieb Jakob Reschke < forums.jakob@resfarm.de>:
HI,
Unless there is a good reason why handling ProvideAnswerNotification is not a good idea in scripted environments, I agree with Chris. I would prefer using the existing mechanism to introducing a strange synonym for Notification.
Swapping the control flow, like Christoph proposed (user code signals the notification and defaultAction is the modal dialog), sounds ok to me too. It would also mean that user code does not have to access the UIManager singleton. On the other hand, it is less obvious whether something is meant to be a UI interaction if the names of the Notifications make the code strange to read. For the most basic cases, at least there still is Object>>inform:/confirm:/confirm:orCancel:.
Kind regards, Jakob
Am Mi., 26. Feb. 2020 um 22:41 Uhr schrieb Chris Muller < asqueaker@gmail.com>:
Hi Marcel,
especially for this one tiny little thing of a modal alert when
renaming classes?
It is a more general issue. There should be no UI invocation code in a
non-UI part of the system. So, "Transcript showln:." is fine but "self inform:" is not. Why? Because those cannot be trapped in scripts, which is
- for example - unfortunate in automated pipelines such as our CI.
Actually, they can.
"example 1" [ self inform: 'stop everything and pay attention to me!' ] on:ProvideAnswerNotification do: [ : noti | noti resume ] "nil"
"example 2" [UIManager default request: 'what is the answer?' initialAnswer:'tell me now!' ] on: ProvideAnswerNotification do: [ : noti | noti resume: 42 ] "42 "
I assumed this is what the CI jobs were doing.. they're not?
I totally share your sentiments about no UI invocation code in the
domain, and is how I do my own designs, of course, but Squeak chose default to being an <<interactive system>>, and requires handlers of ProvideAnswerNotification to make it non-interactive, rather than the other way around.
If you want to flip the above in 5.4 to the normal way -- signaling a
kind of ProvideAnswerNotification whose defaultAction issues the modal popup -- then let's flip them, but it doesn't seem like we need a new layer of notification classes just yet. ProvideAnswerNotification may be sufficient.
Best, Chris
What happened to simply opening up a MessageSet on the references
afterward?
Still there. Unrelated to this issue. See the end of Browser >>
#renameClass.
Say, why do we need a modal alert at all?
I agree, that extra check in Class >> #rename: might not be necessary
and maybe moved to our refactoring tools.
Best, Marcel
Am 26.02.2020 00:21:48 schrieb Chris Muller asqueaker@gmail.com:
-1. "Notice" is such a generic, common word to steal from all
applications that might want to create their own, especially for this one tiny little thing of a modal alert when renaming classes? Say, why do we need a modal alert at all? What happened to simply opening up a MessageSet on the references afterward?
- Chris
On Tue, Feb 25, 2020 at 8:17 AM Marcel Taeumel marcel.taeumel@hpi.de
wrote:
Just "Notice"?
Am 25.02.2020 12:11:33 schrieb Eliot Miranda <eliot.miranda@gmail.com
:
On Feb 25, 2020, at 1:40 AM, Marcel Taeumel marcel.taeumel@hpi.de
wrote:
Fixed. BUT: Please take a look at
Kernel-mt.1305 Tools-mt.941
We need a name! :-)
On second thoughts Notice might be a better name.
Best, Marcel
Am 25.02.2020 10:11:22 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Maybe it is a sporadic issue?
It is! Related to the ProgressNotification which I accidentially catch
in Browser >> #renameClass. I wanted to get the UI call out of Class >> #rename:.
That progress notification does not appear every time. Only above a
certain threshold. That's why it appears to be sporadic.
Best, Marcel
Am 25.02.2020 09:37:13 schrieb Thiede, Christoph <
christoph.thiede@student.hpi.uni-potsdam.de>:
I could reproduce it one single time ... Maybe it is a sporadic issue?
Best,
Christoph
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im
Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 25. Februar 2020 09:34:03 An: John Pfersich via Squeak-dev; Chris Muller Betreff: Re: [squeak-dev] 5.3 cannot rename subclasses of Error
Hmm... I can reproduce the bug. Yet, calling "Error2 rename: #Error1"
from a workspace works fine. Strange.
Best, Marcel
Am 25.02.2020 09:16:13 schrieb Thiede, Christoph <
christoph.thiede@student.hpi.uni-potsdam.de>:
Hi Chris,
in a fresh image, I cannot reproduce this. Are you sure the class has
not been renamed or is it possible that the class list was not updated properly?
Best,
Christoph
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im
Auftrag von Chris Muller asqueaker@gmail.com
Gesendet: Dienstag, 25. Februar 2020 06:29:00 An: squeak dev Betreff: [squeak-dev] 5.3 cannot rename subclasses of Error
In trunk / 5.3 RC.
- Make a subclass of Error called MyError1
- Make a subclass of Error called MyError2
- Delete MyError1
- Try to rename MyError2 to MyError1
The last step fails. No errors or debuggers, but the class is not
renamed.
Works in 5.2.
Hi Jakob,
really great to read your thoughts about this topic! :D
UserRequest (base class)
"Christoph proposed UserNotification, but notifications can be dismissed easily, confirmations or choices should not be" "Also Monticello and other packages already use *Request for the purpose" InputRequest "accurate, but too general?" Request "probably too general"
Hm, is an #inform: really a request? (One could say: yes, a request for "okay", but that's a bit philosophical ^^) However, +1 for not naming it *Notification. In most cases, it would not be even useful to provide a non-parametrized version of #resume.
"asynchronous/continuation style:" (InputRequestSubclass signal) eventually: [:response | ... ]; then: [:response | ...]; ifRejected:/ifCancelled: [...].
I never used this in practice, but it sounds useful in certain situations. But how would you implement this? Exception does not inherit from Promise.
"remains open whether this will be a modal popup or a message in some kind of notification area"
Notification area? Interesting concept, you're ahead of our time in Squeak ;-) OT: Actually, I would find it more interesting/urgent to support true multiprocessing than any kind of notification area which is mainly useful if it is filled asynchronously. Another approach might be PHNotificationhttps://github.com/tom95/Pheno/tree/master/src/Pheno-Examples.package/PHNotificationExample.class, but in general, I wonder how often developers need any secondary notification? They are mostly not so relevant and cleaning up any additional notification area can cost time and nerves ...
ConfirmationRequest signal: 'More letters, but looks nicer to me' trueChoice: #Agreed falseChoice: #Disagreed. on: ConfirmationRequest do: [:request | request resume:/respond:/reply:/answer:/choose: #Agreeable].
What for do you need the symbols?
(ConfirmationRequest signal: 'Do you love Squeak?') ifTrue: [UserInformation signal: 'I love you too!'] ifFalse: [ActiveHand openInHand "revenge"].
MultipleChoiceRequest signal: 'I think it is...' choices: #(Good Bad Done) labels: #(Yay Nay What)
Do we actually need two arrays that are connected implicitly via index? This feels kind of out-dated for me. We could use
MultipleChoiceRequest signal: 'What would you like to do?' choices: { 'Open a Browser' -> [Browser open]. 'Open a TestRunner' -> [TestRunner open]. 'Open the help' -> [HelpBrowser open] }
... or something similar. See also #chooseFromLabeledValues:.
XyzRequestedFromUser signal: 'More explicit purpose, but yet another naming style'
Past participle indicates past, I'd prefer ResourceRequest or so.
File/Font/String/Text/Password/Credentials/ObjectRequest/ed signal: 'Likewise' initialAnswer: whatever. "Makes me wonder whether UserRequest might imply that a user must be chosen instead of requesting something from users" [...] "Can there be a protocol to request a certain kind of object from the user or would we really need one subclass for each kind?" Xyz requestFromUser: 'Choose your Xyz...'. on: Xyz input/userRequest do: [:request | ...]. InputRequest signal: 'Choose your object' ofKind: Xyz. on: InputRequest do: [:request | (request acceptsA/n: Xyz) ifTrue: [...] ifFalse: [request pass]]. ...
How about:
FileDirectory class >> #resourceRequest ^ CustomResourceRequest new defaultBlock: [self default]; uiBlock: [:request | DirectoryChooserDialog openOn: self default label: request messageText]; yourself
"Usage:" FileDirectory resourceRequest signal: 'Please enter a directory for purpose foo!'. "Maybe with property dictionary:" FileDirectory resourceRequest setProperty: #rootDirectory toValue: (FileDirectory on: 'c:'); signal: 'Please enter a directory for purpose foo!'.
"Second example:" SystemWindow class >> #resourceRequest ^ CustomResourceRequest new resourceString: 'window'; "for generating default messageText" uiBlock: [:request | UserChoiceRequest signal: request messageText choices: (SystemWindow windowsIn: self currentWorld)]]; yourself
"Usage:" SystemWindow resourceRequest signal ifNotNil: [:window | window comeToFront].
Or would this be too generic? Oh, what a fun to brainstorm a new object design :-)
Best, Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke forums.jakob@resfarm.de Gesendet: Freitag, 28. Februar 2020 23:55:12 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Separation of domain from UI in Squeak (was: 5.3 cannot rename subclasses of Error)
Thinking about names and usage...
UserRequest (base class) "Christoph proposed UserNotification, but notifications can be dismissed easily, confirmations or choices should not be" "Also Monticello and other packages already use *Request for the purpose" InputRequest "accurate, but too general?" Request "probably too general" "contrast with WebRequest, for example" "asynchronous/continuation style:" (InputRequestSubclass signal) eventually: [:response | ... ]; then: [:response | ...]; ifRejected:/ifCancelled: [...]. "handling:" on: InputRequest do: [:request | request resume:/provide:/answer:/reply:/respond: whatever].
UserInformation signalWith: 'Looks ok' "remains open whether this will be a modal popup or a message in some kind of notification area" on: UserInformation do: [:info | info resume/dismiss/accept/continue "ok"] "but it might also be information about (not for) a user" UserNotification signalWith: 'This makes more sense to me here for inform:'. "This is not really a request for information, only for acknowledgement"
UserConfirmation signal .... "strange because here we want to request confirmation, not give one" UserConfirmation request: 'Does this look better?' "but signal is still inherited" on: UserConfirmation do: [:confirm | "strange again because the confirmation is yet to be given or denied"] UserConfirmRequest signal: 'This looks wordy even though it is already abbreviated' UserConfirmRequest request: 'Double double words'. UserConfirmRequest confirm: 'Double double, and the request shall confirm something??' "can be circumvented with a UserConfirmation factory but then signalling and handling use different class names" ConfirmationRequest signal: 'More letters, but looks nicer to me' trueChoice: #Agreed falseChoice: #Disagreed. on: ConfirmationRequest do: [:request | request resume:/respond:/reply:/answer:/choose: #Agreeable]. on: ConfirmationRequest do: [:request | request confirm/deny]. "ConfirmationRequested also possible, but not a noun -- different style"
MultipleChoiceRequest signal: 'I think it is...' choices: #(Good Bad Done) labels: #(Yay Nay What) "unfortunately the class name is already taken in RefactoringTools" ChoiceRequest signal: 'shorter but maybe stranger?' choices: #(Yep Nope) MultiResponseRequest signal: 'I like...' responses: #(Cats Dogs Squeak You) "funnily the term 'multiple choice' implies a single answer from a set of many" ConfirmationRequest "or others (see above) could also be a subclass of multiple choice" ClassOrTraitRequest signal: 'Choose your request'. (ClassOrTraitRequest fromPattern: '*Class*Request') signal: 'Other ideas?' ClassifierRequest signal: 'Do you prefer UML-speak?' DirectoryRequest signal: 'What kinds of other requests to/from/by/with/... a directory are there?' DirectoryRequested signal: 'This might be less ambiguous' File/Font/String/Text/Password/Credentials/ObjectRequest/ed signal: 'Likewise' initialAnswer: whatever. "Makes me wonder whether UserRequest might imply that a user must be chosen instead of requesting something from users" XyzRequestedFromUser signal: 'More explicit purpose, but yet another naming style' "Can there be a protocol to request a certain kind of object from the user or would we really need one subclass for each kind?" Xyz requestFromUser: 'Choose your Xyz...'. on: Xyz input/userRequest do: [:request | ...]. InputRequest signal: 'Choose your object' ofKind: Xyz. on: InputRequest do: [:request | (request acceptsA/n: Xyz) ifTrue: [...] ifFalse: [request pass]]. ...
There is also ProgressInitiationException which does not have a nice name. It is not a request, but it already has displayProgress:* in UIManager as defaultAction. Alternative names: ProgressInitiation/ed ProgressStart/ed
Am Fr., 28. Feb. 2020 um 22:11 Uhr schrieb Jakob Reschke <forums.jakob@resfarm.demailto:forums.jakob@resfarm.de>: HI,
Unless there is a good reason why handling ProvideAnswerNotification is not a good idea in scripted environments, I agree with Chris. I would prefer using the existing mechanism to introducing a strange synonym for Notification.
Swapping the control flow, like Christoph proposed (user code signals the notification and defaultAction is the modal dialog), sounds ok to me too. It would also mean that user code does not have to access the UIManager singleton. On the other hand, it is less obvious whether something is meant to be a UI interaction if the names of the Notifications make the code strange to read. For the most basic cases, at least there still is Object>>inform:/confirm:/confirm:orCancel:.
Kind regards, Jakob
Am Mi., 26. Feb. 2020 um 22:41 Uhr schrieb Chris Muller <asqueaker@gmail.commailto:asqueaker@gmail.com>:
Hi Marcel,
especially for this one tiny little thing of a modal alert when renaming classes?
It is a more general issue. There should be no UI invocation code in a non-UI part of the system. So, "Transcript showln:." is fine but "self inform:" is not. Why? Because those cannot be trapped in scripts, which is - for example - unfortunate in automated pipelines such as our CI.
Actually, they can.
"example 1" [ self inform: 'stop everything and pay attention to me!' ] on: ProvideAnswerNotification do: [ : noti | noti resume ] "nil" "example 2" [UIManager default request: 'what is the answer?' initialAnswer: 'tell me now!' ] on: ProvideAnswerNotification do: [ : noti | noti resume: 42 ] "42 "I assumed this is what the CI jobs were doing.. they're not?
I totally share your sentiments about no UI invocation code in the domain, and is how I do my own designs, of course, but Squeak chose default to being an <<interactive system>>, and requires handlers of ProvideAnswerNotification to make it non-interactive, rather than the other way around.
If you want to flip the above in 5.4 to the normal way -- signaling a kind of ProvideAnswerNotification whose defaultAction issues the modal popup -- then let's flip them, but it doesn't seem like we need a new layer of notification classes just yet. ProvideAnswerNotification may be sufficient.
Best, Chris
What happened to simply opening up a MessageSet on the references afterward?
Still there. Unrelated to this issue. See the end of Browser >> #renameClass.
Say, why do we need a modal alert at all?
I agree, that extra check in Class >> #rename: might not be necessary and maybe moved to our refactoring tools.
Best, Marcel
Am 26.02.2020 00:21:48 schrieb Chris Muller <asqueaker@gmail.commailto:asqueaker@gmail.com>:
-1. "Notice" is such a generic, common word to steal from all applications that might want to create their own, especially for this one tiny little thing of a modal alert when renaming classes? Say, why do we need a modal alert at all? What happened to simply opening up a MessageSet on the references afterward?
- Chris
On Tue, Feb 25, 2020 at 8:17 AM Marcel Taeumel <marcel.taeumel@hpi.demailto:marcel.taeumel@hpi.de> wrote:
Just "Notice"?
Am 25.02.2020 12:11:33 schrieb Eliot Miranda <eliot.miranda@gmail.commailto:eliot.miranda@gmail.com>:
On Feb 25, 2020, at 1:40 AM, Marcel Taeumel <marcel.taeumel@hpi.demailto:marcel.taeumel@hpi.de> wrote:
Fixed. BUT: Please take a look at
Kernel-mt.1305 Tools-mt.941
We need a name! :-)
On second thoughts Notice might be a better name.
Best, Marcel
Am 25.02.2020 10:11:22 schrieb Marcel Taeumel <marcel.taeumel@hpi.demailto:marcel.taeumel@hpi.de>:
Maybe it is a sporadic issue?
It is! Related to the ProgressNotification which I accidentially catch in Browser >> #renameClass. I wanted to get the UI call out of Class >> #rename:.
That progress notification does not appear every time. Only above a certain threshold. That's why it appears to be sporadic.
Best, Marcel
Am 25.02.2020 09:37:13 schrieb Thiede, Christoph <christoph.thiede@student.hpi.uni-potsdam.demailto:christoph.thiede@student.hpi.uni-potsdam.de>:
I could reproduce it one single time ... Maybe it is a sporadic issue?
Best,
Christoph
Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.orgmailto:squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 25. Februar 2020 09:34:03 An: John Pfersich via Squeak-dev; Chris Muller Betreff: Re: [squeak-dev] 5.3 cannot rename subclasses of Error
Hmm... I can reproduce the bug. Yet, calling "Error2 rename: #Error1" from a workspace works fine. Strange.
Best, Marcel
Am 25.02.2020 09:16:13 schrieb Thiede, Christoph <christoph.thiede@student.hpi.uni-potsdam.demailto:christoph.thiede@student.hpi.uni-potsdam.de>:
Hi Chris,
in a fresh image, I cannot reproduce this. Are you sure the class has not been renamed or is it possible that the class list was not updated properly?
Best,
Christoph
Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.orgmailto:squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Chris Muller <asqueaker@gmail.commailto:asqueaker@gmail.com> Gesendet: Dienstag, 25. Februar 2020 06:29:00 An: squeak dev Betreff: [squeak-dev] 5.3 cannot rename subclasses of Error
In trunk / 5.3 RC.
- Make a subclass of Error called MyError1
- Make a subclass of Error called MyError2
- Delete MyError1
- Try to rename MyError2 to MyError1
The last step fails. No errors or debuggers, but the class is not renamed.
Works in 5.2.
Am Sa., 29. Feb. 2020 um 09:59 Uhr schrieb Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de:
"asynchronous/continuation style:" (InputRequestSubclass signal) eventually: [:response | ... ]; then: [:response | ...]; ifRejected:/ifCancelled: [...].
I never used this in practice, but it sounds useful in certain situations. But how would you implement this? Exception does not inherit from Promise.
That does not mean that an exception subclass cannot share some of the protocol of Promise. In the implementation, a Promise could be generated. If the exception is handled, the Promise could be resolved immediately. Otherwise it would be resolved or rejected once the button is pressed in the dialog box.
But the other day I noticed a drawback of the Promise usage: errors signaled in the code invoked by the answer (e. g. clicking a button) do not open a debugger, but reject the promise instead. The exception is passed to the reject block, but if you chain promises together, you cannot simply resignal or pass that on, since it will just be caught again by the next nested promise.
"remains open whether this will be a modal popup or a message in some kind of notification area"Notification area? Interesting concept, you're ahead of our time in Squeak ;-)
Well, Pharo already has one, Windows and probably all other major OSs have had it for ages, nothing new here. :-) You could even sell a Transcript as notification area if you manage to catch attention after you wrote to it. Chris rightfully questioned if the interruption of the modal dialog was necessary at all. In the case of inform: you don't really have an official way to cancel what is about to happen. I don't recognize un-modalizing the dialog box or interrupting with a debugger as official ways...
ConfirmationRequest signal: 'More letters, but looks nicer to me' trueChoice: #Agreed falseChoice: #Disagreed. on: ConfirmationRequest do: [:request | request resume:/respond:/reply:/answer:/choose: #Agreeable].What for do you need the symbols?
They are just examples and could also be strings or anything to choose from. In this case I wanted to demonstrate how today's confirm:trueChoice:falseChoice: could look like. The confirm:* messages convert a choice from two possible answers into a boolean.
(ConfirmationRequest signal: 'Do you love Squeak?') ifTrue: [UserInformation signal: 'I love you too!'] ifFalse: [ActiveHand openInHand "revenge"].
MultipleChoiceRequest signal: 'I think it is...' choices: #(Good Bad Done) labels: #(Yay Nay What)Do we actually need two arrays that are connected implicitly via index? This feels kind of out-dated for me. We could use [...]
I simply took the existing UIManager messages and transformed that into some similar exception protocol. The final messages can look different, of course.
XyzRequestedFromUser signal: 'More explicit purpose, but yet another naming style'Past participle indicates past, I'd prefer ResourceRequest or so.
Yes I noticed that too. The past participle names sound more like events. They look good at the handler site, but a little strange at the signal site where the exception is yet to be signaled.
File/Font/String/Text/Password/Credentials/ObjectRequest/ed signal: 'Likewise' initialAnswer: whatever. "Makes me wonder whether UserRequest might imply that a user must be chosen instead of requesting something from users" [...] "Can there be a protocol to request a certain kind of object from the user or would we really need one subclass for each kind?" Xyz requestFromUser: 'Choose your Xyz...'. on: Xyz input/userRequest do: [:request | ...]. InputRequest signal: 'Choose your object' ofKind: Xyz. on: InputRequest do: [:request | (request acceptsA/n: Xyz) ifTrue: [...] ifFalse: [request pass]]. ...How about:
FileDirectory class >> #resourceRequest ^ CustomResourceRequest new defaultBlock: [self default]; uiBlock: [:request | DirectoryChooserDialog openOn: self default label: request messageText]; yourself
How or under which circumstances are the blocks invoked? What is the purpose of the default? Why is it called "custom"? Please consider this as a reviewer's challenge, not as criticism. :-)
In this example the UI code is in the domain class (FileDirectory) again, which we strived to avoid, didn't we?
"Usage:" FileDirectory resourceRequest signal: 'Please enter a directory for purpose foo!'. "Maybe with property dictionary:" FileDirectory resourceRequest setProperty: #rootDirectory toValue: (FileDirectory on: 'c:');
Hmm these are fancy maps instead of properly typed objects. At first glance I don't like that very much. Are lots of (auto-generated?) subclasses better after all? Or in this case a custom solution:
(FileDirectory on: 'C:') subdirectoryRequest signal: ...
How does the handler look like? on: CustomResourceRequest do: [...] looks strange to me if I want to handle a multiple choice or a file open dialog (CustomResource too unspecific). Could be solved by a message sent to the domain class, the answer being the appropriate exception to handle. on: FileDirectory resourceRequest do: ...but in this case you already used this particular selector for the exception factory. Could be easily transformed to resourceRequest new, though. Still if the class answers the generic CustomResourceRequest, you might inadvertently handle a request for a dinosaur when you really only wanted to handle the request for a directory. So I think we either need specific exception classes, some type-checking condition in the exception handler, or a new kind of exception selector (like ExceptionSet) that does the additional type-checking. on: (CustomResourceRequest for: FileDirectory) do:
The combination of resource and request also makes me think of REST, which is clearly not what this is about.
"Second example:" SystemWindow class >> #resourceRequest ^ CustomResourceRequest new resourceString: 'window'; "for generating default messageText" uiBlock: [:request | UserChoiceRequest signal: request messageText choices: (SystemWindow windowsIn: self currentWorld)]]; yourself
"Usage:" SystemWindow resourceRequest signal ifNotNil: [:window | window comeToFront].
Or would this be too generic?
Apart from the mixture of domain and UI... to check, I suggest you imagine how it maps to the existing requests in UIManager. In this particular example with SystemWindow (and I understand that you want to choose from all windows in the current world, right?), I find the window argument to the ifNotNil: block confusing. Is this the chosen window (the result) or is it a window opened by the UserChoiceRequest? Probably the former. There are two exceptions here: CustomResourceRequest and UserChoiceRequest. Is that really necessary for a single use case? Which one would you handle in user code, under which circumstances? I guess this also provoked my confusion about the :window...
Kind regards, Jakob
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke forums.jakob@resfarm.de Gesendet: Freitag, 28. Februar 2020 23:55:12 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Separation of domain from UI in Squeak (was: 5.3 cannot rename subclasses of Error)
Thinking about names and usage...
UserRequest (base class) "Christoph proposed UserNotification, but notifications can be dismissed easily, confirmations or choices should not be" "Also Monticello and other packages already use *Request for the purpose" InputRequest "accurate, but too general?" Request "probably too general" "contrast with WebRequest, for example" "asynchronous/continuation style:" (InputRequestSubclass signal) eventually: [:response | ... ]; then: [:response | ...]; ifRejected:/ifCancelled: [...]. "handling:" on: InputRequest do: [:request | request resume:/provide:/answer:/reply:/respond: whatever].
UserInformation signalWith: 'Looks ok' "remains open whether this will be a modal popup or a message in some kind of notification area" on: UserInformation do: [:info | info resume/dismiss/accept/continue "ok"] "but it might also be information about (not for) a user" UserNotification signalWith: 'This makes more sense to me here for inform:'. "This is not really a request for information, only for acknowledgement" UserConfirmation signal .... "strange because here we want to request confirmation, not give one" UserConfirmation request: 'Does this look better?' "but signal is still inherited" on: UserConfirmation do: [:confirm | "strange again because the confirmation is yet to be given or denied"] UserConfirmRequest signal: 'This looks wordy even though it is already abbreviated' UserConfirmRequest request: 'Double double words'. UserConfirmRequest confirm: 'Double double, and the request shall confirm something??' "can be circumvented with a UserConfirmation factory but then signalling and handling use different class names" ConfirmationRequest signal: 'More letters, but looks nicer to me' trueChoice: #Agreed falseChoice: #Disagreed. on: ConfirmationRequest do: [:request | request resume:/respond:/reply:/answer:/choose: #Agreeable]. on: ConfirmationRequest do: [:request | request confirm/deny]. "ConfirmationRequested also possible, but not a noun -- different style" MultipleChoiceRequest signal: 'I think it is...' choices: #(Good Bad Done) labels: #(Yay Nay What) "unfortunately the class name is already taken in RefactoringTools" ChoiceRequest signal: 'shorter but maybe stranger?' choices: #(Yep Nope) MultiResponseRequest signal: 'I like...' responses: #(Cats Dogs Squeak You) "funnily the term 'multiple choice' implies a single answer from a set of many" ConfirmationRequest "or others (see above) could also be a subclass of multiple choice" ClassOrTraitRequest signal: 'Choose your request'. (ClassOrTraitRequest fromPattern: '*Class*Request') signal: 'Other ideas?' ClassifierRequest signal: 'Do you prefer UML-speak?' DirectoryRequest signal: 'What kinds of other requests to/from/by/with/... a directory are there?' DirectoryRequested signal: 'This might be less ambiguous' File/Font/String/Text/Password/Credentials/ObjectRequest/ed signal: 'Likewise' initialAnswer: whatever. "Makes me wonder whether UserRequest might imply that a user must be chosen instead of requesting something from users" XyzRequestedFromUser signal: 'More explicit purpose, but yet another naming style' "Can there be a protocol to request a certain kind of object from the user or would we really need one subclass for each kind?" Xyz requestFromUser: 'Choose your Xyz...'. on: Xyz input/userRequest do: [:request | ...]. InputRequest signal: 'Choose your object' ofKind: Xyz. on: InputRequest do: [:request | (request acceptsA/n: Xyz) ifTrue: [...] ifFalse: [request pass]]. ...There is also ProgressInitiationException which does not have a nice name. It is not a request, but it already has displayProgress:* in UIManager as defaultAction. Alternative names: ProgressInitiation/ed ProgressStart/ed
Am Fr., 28. Feb. 2020 um 22:11 Uhr schrieb Jakob Reschke forums.jakob@resfarm.de:
HI,
Unless there is a good reason why handling ProvideAnswerNotification is not a good idea in scripted environments, I agree with Chris. I would prefer using the existing mechanism to introducing a strange synonym for Notification.
Swapping the control flow, like Christoph proposed (user code signals the notification and defaultAction is the modal dialog), sounds ok to me too. It would also mean that user code does not have to access the UIManager singleton. On the other hand, it is less obvious whether something is meant to be a UI interaction if the names of the Notifications make the code strange to read. For the most basic cases, at least there still is Object>>inform:/confirm:/confirm:orCancel:.
Kind regards, Jakob
Am Mi., 26. Feb. 2020 um 22:41 Uhr schrieb Chris Muller asqueaker@gmail.com:
Hi Marcel,
especially for this one tiny little thing of a modal alert when renaming classes?
It is a more general issue. There should be no UI invocation code in a non-UI part of the system. So, "Transcript showln:." is fine but "self inform:" is not. Why? Because those cannot be trapped in scripts, which is - for example - unfortunate in automated pipelines such as our CI.
Actually, they can.
"example 1" [ self inform: 'stop everything and pay attention to me!' ] on: ProvideAnswerNotification do: [ : noti | noti resume ] "nil" "example 2" [UIManager default request: 'what is the answer?' initialAnswer: 'tell me now!' ] on: ProvideAnswerNotification do: [ : noti | noti resume: 42 ] "42 "I assumed this is what the CI jobs were doing.. they're not?
I totally share your sentiments about no UI invocation code in the domain, and is how I do my own designs, of course, but Squeak chose default to being an <<interactive system>>, and requires handlers of ProvideAnswerNotification to make it non-interactive, rather than the other way around.
If you want to flip the above in 5.4 to the normal way -- signaling a kind of ProvideAnswerNotification whose defaultAction issues the modal popup -- then let's flip them, but it doesn't seem like we need a new layer of notification classes just yet. ProvideAnswerNotification may be sufficient.
Best, Chris
What happened to simply opening up a MessageSet on the references afterward?
Still there. Unrelated to this issue. See the end of Browser >> #renameClass.
Say, why do we need a modal alert at all?
I agree, that extra check in Class >> #rename: might not be necessary and maybe moved to our refactoring tools.
Best, Marcel
Am 26.02.2020 00:21:48 schrieb Chris Muller asqueaker@gmail.com:
-1. "Notice" is such a generic, common word to steal from all applications that might want to create their own, especially for this one tiny little thing of a modal alert when renaming classes? Say, why do we need a modal alert at all? What happened to simply opening up a MessageSet on the references afterward?
- Chris
On Tue, Feb 25, 2020 at 8:17 AM Marcel Taeumel marcel.taeumel@hpi.de wrote:
Just "Notice"?
Am 25.02.2020 12:11:33 schrieb Eliot Miranda eliot.miranda@gmail.com:
On Feb 25, 2020, at 1:40 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Fixed. BUT: Please take a look at
Kernel-mt.1305 Tools-mt.941
We need a name! :-)
On second thoughts Notice might be a better name.
Best, Marcel
Am 25.02.2020 10:11:22 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Maybe it is a sporadic issue?
It is! Related to the ProgressNotification which I accidentially catch in Browser >> #renameClass. I wanted to get the UI call out of Class >> #rename:.
That progress notification does not appear every time. Only above a certain threshold. That's why it appears to be sporadic.
Best, Marcel
Am 25.02.2020 09:37:13 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
I could reproduce it one single time ... Maybe it is a sporadic issue?
Best,
Christoph
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 25. Februar 2020 09:34:03 An: John Pfersich via Squeak-dev; Chris Muller Betreff: Re: [squeak-dev] 5.3 cannot rename subclasses of Error
Hmm... I can reproduce the bug. Yet, calling "Error2 rename: #Error1" from a workspace works fine. Strange.
Best, Marcel
Am 25.02.2020 09:16:13 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Chris,
in a fresh image, I cannot reproduce this. Are you sure the class has not been renamed or is it possible that the class list was not updated properly?
Best,
Christoph
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Chris Muller asqueaker@gmail.com Gesendet: Dienstag, 25. Februar 2020 06:29:00 An: squeak dev Betreff: [squeak-dev] 5.3 cannot rename subclasses of Error
In trunk / 5.3 RC.
- Make a subclass of Error called MyError1
- Make a subclass of Error called MyError2
- Delete MyError1
- Try to rename MyError2 to MyError1
The last step fails. No errors or debuggers, but the class is not renamed.
Works in 5.2.
On 2020-02-28, at 1:11 PM, Jakob Reschke forums.jakob@resfarm.de wrote:
HI,
Unless there is a good reason why handling ProvideAnswerNotification is not a good idea in scripted environments, I agree with Chris. I would prefer using the existing mechanism to introducing a strange synonym for Notification.
Of course, one could provide a script handling method (I'd swear Chris mentioned one he use a while back but I can't think of it right now... oh wait, "Smalltalk run:[]" ) that catches the ProvideAnswerNotification and converts it to an other-way-round exception. An obvious problem with the current implementation is that it carries very little helpful information (notwithstanding Marcel's BlockClosure>>#valueSupplyingAnswers: try-to-do-it-all method) for the handler to decode. We seem to need to know an awful lot about what is going on in called code.
It might be neat if we could find a way to handle the exception within a terminal environment; maybe with 'curses' (that's probably dating me horribly) or zenity or whatever. Possibly helpful for nominally headless setups?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Hackers have kernel knowledge.
Am Sa., 29. Feb. 2020 um 03:23 Uhr schrieb tim Rowledge tim@rowledge.org:
An obvious problem with the current implementation is that it carries very little helpful information (notwithstanding Marcel's BlockClosure>>#valueSupplyingAnswers: try-to-do-it-all method) for the handler to decode. We seem to need to know an awful lot about what is going on in called code.
Agreed. And in a catch-all handler, how do you know which details you can access in the current handler invocation?
It might be neat if we could find a way to handle the exception within a terminal environment; maybe with 'curses' (that's probably dating me horribly) or zenity or whatever. Possibly helpful for nominally headless setups?
If we had all these request exceptions Christoph and me are writing about, I'd imagine the fallback handlers would sit in the Project subclass. MorphicProject opens the UserDialogBoxMorph, MVCProject does its equivalent thing, HeadlessProject must already know all the answers or abort with an error, TerminalProject (sounds like the last one before the program dies...) pops up the request with the imaginary curses UI.
Also note that opening a debugger is a special case of all of this: the debugger is the UI for the request of how to proceed in the event of an error, warning or interrupt/halt/breakpoint.
Hi all! :-)
Here is a more general thought:
Working with ProvideAnswerNotification is too brittle for tests. It is basically useless when using localization (String >> #translated). One cannot expect the translator to also translate all those patterns for ProvideAnswerNotification.
The explicit use of a RemarkNotification (or similar) improves modularity by decoupling the mechanism from UI texts.
Just my two cents. :-) Let's work on that in 6.0alpha. Christoph (ct) has some interesting ideas in this regard.
Best, Marcel Am 29.02.2020 18:48:22 schrieb Jakob Reschke forums.jakob@resfarm.de: Am Sa., 29. Feb. 2020 um 03:23 Uhr schrieb tim Rowledge :
An obvious problem with the current implementation is that it carries very little helpful information (notwithstanding Marcel's BlockClosure>>#valueSupplyingAnswers: try-to-do-it-all method) for the handler to decode. We seem to need to know an awful lot about what is going on in called code.
Agreed. And in a catch-all handler, how do you know which details you can access in the current handler invocation?
It might be neat if we could find a way to handle the exception within a terminal environment; maybe with 'curses' (that's probably dating me horribly) or zenity or whatever. Possibly helpful for nominally headless setups?
If we had all these request exceptions Christoph and me are writing about, I'd imagine the fallback handlers would sit in the Project subclass. MorphicProject opens the UserDialogBoxMorph, MVCProject does its equivalent thing, HeadlessProject must already know all the answers or abort with an error, TerminalProject (sounds like the last one before the program dies...) pops up the request with the imaginary curses UI.
Also note that opening a debugger is a special case of all of this: the debugger is the UI for the request of how to proceed in the event of an error, warning or interrupt/halt/breakpoint.
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Jakob Reschke -
Marcel Taeumel -
Thiede, Christoph -
tim Rowledge