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 at 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 at 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 at hpi.de> wrote:
>>>
>>> Just "Notice"?
>>>
>>> Am 25.02.2020 12:11:33 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>>>
>>>
>>>
>>> On Feb 25, 2020, at 1:40 AM, Marcel Taeumel <marcel.taeumel at 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 at 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 at 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 at 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 at 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 at lists.squeakfoundation.org> im Auftrag von Chris Muller <asqueaker at 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.
>>>
>>>
>>>
>>
>