<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p>Hi Jakob,</p>
<p><br>
</p>
<p>really great to read your thoughts about this topic! :D</p>
<p><br>
</p>
<p>> <span style="font-size: 12pt;">UserRequest (base class)</span></p>
<div>> "Christoph proposed UserNotification, but notifications can be</div>
<div>> dismissed easily, confirmations or choices should not be"</div>
<div>
<div>> "Also Monticello and other packages already use *Request for the purpose"</div>
<div>> InputRequest "accurate, but too general?"</div>
<div>> Request "probably too general"</div>
<div><br>
</div>
</div>
<div>Hm, is an #inform: really a request? (One could say: yes, a request for "okay", but that's a bit philosophical ^^)</div>
<div>However, +1 for not naming it *Notification. In most cases, it would not be even useful to provide a non-parametrized version of #resume.</div>
<div><br>
</div>
<div>
<div>> "asynchronous/continuation style:"</div>
<div>> (InputRequestSubclass signal)</div>
<div>> eventually: [:response | ... ];</div>
<div>> then: [:response | ...];</div>
<div>> ifRejected:/ifCancelled: [...].</div>
<div><br>
</div>
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.</div>
<div><br>
</div>
<div>
<div>> <span style="font-size: 12pt;"> "remains open whether this will be a modal popup or a message in some kind of notification area"</span>
<div><br>
</div>
<div>Notification area? Interesting concept, you're ahead of our time in Squeak ;-)</div>
</div>
</div>
<div><span style="font-size: 10pt;">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.</span></div>
<div><span style="font-size: 10pt;">Another approach might be </span><a href="https://github.com/tom95/Pheno/tree/master/src/Pheno-Examples.package/PHNotificationExample.class" class="OWAAutoLink" title="https://github.com/tom95/Pheno/tree/master/src/Pheno-Examples.package/PHNotificationExample.class
Strg+Klicken oder tippen Sie, um dem Link zu folgen."><span style="font-size: 10pt;">PHNotification</span></a><span style="font-size: 10pt;">,
but in general, I wonder how often developers need any secondary notification? They are mostly not so </span><span style="font-size: 10pt;">relevant and cleaning up any additional notification area can cost time and nerves ...</span></div>
<div><br>
</div>
<div>
<div>> ConfirmationRequest signal: 'More letters, but looks nicer to me' trueChoice: #Agreed falseChoice: #Disagreed.</div>
<div>> on: ConfirmationRequest do: [:request | request resume:/respond:/reply:/answer:/choose: #Agreeable].</div>
<div><br>
</div>
What for do you need the symbols?</div>
<div><br>
</div>
<div>(ConfirmationRequest signal: 'Do you love Squeak?')</div>
<div> ifTrue: [<span>UserInformation signal: 'I love you too!']</span></div>
<div><span> ifFalse: [ActiveHand openInHand "revenge"].</span></div>
<div><span><br>
</span></div>
<div><span>> </span><span style="font-size: 12pt;"> MultipleChoiceRequest signal: 'I think it is...' choices: #(Good Bad Done) labels: #(Yay Nay What)</span><span>
<div><br>
</div>
<div>Do we actually need two arrays that are connected implicitly via index? This feels kind of out-dated for me. We could use</div>
<div><br>
</div>
<div><span>MultipleChoiceRequest signal: 'What would you like to do?' choices: {</span><br>
</div>
<div><span> 'Open a Browser' -> [Browser open].</span></div>
<div><span> 'Open a TestRunner' -> [TestRunner open].</span></div>
<div><span> 'Open the help' -> [HelpBrowser open] }</span></div>
<div><span><br>
</span></div>
<div><span>... or something similar. See also #<span>chooseFromLabeledValues:.</span></span></div>
<div><span><br>
</span></div>
<div><span>> </span><span style="font-size: 12pt;"> XyzRequestedFromUser signal: 'More explicit purpose, but yet another naming style'</span><span>
<div><br>
</div>
<div>Past participle indicates past, I'd prefer ResourceRequest or so.</div>
<div><br>
</div>
<div>
<div>> File/Font/String/Text/Password/Credentials/ObjectRequest/ed signal: 'Likewise' initialAnswer: whatever.</div>
<div>> "Makes me wonder whether UserRequest might imply that a user must be chosen</div>
<div>> instead of requesting something from users"</div>
<div>> [...]</div>
<div><span style="font-size: 12pt;">> "Can there be a protocol to request a certain kind of object from the user</span><br>
</div>
<div>> or would we really need one subclass for each kind?"</div>
<div>> Xyz requestFromUser: 'Choose your Xyz...'.</div>
<div>> on: Xyz input/userRequest do: [:request | ...].</div>
<div>> InputRequest signal: 'Choose your object' ofKind: Xyz.</div>
<div>> on: InputRequest do: [:request | (request acceptsA/n: Xyz) ifTrue: [...] ifFalse: [request pass]].</div>
<div>> ...</div>
<div><br>
</div>
How about:</div>
<div><br>
</div>
<div>FileDirectory class >> #resourceRequest</div>
<div> ^ CustomResourceRequest new</div>
<div> defaultBlock: [self default];</div>
<div> uiBlock: [:request | DirectoryChooserDialog openOn: self default label: request messageText];</div>
<div> yourself</div>
<div><br>
</div>
<div>"Usage:"</div>
<div>FileDirectory resourceRequest signal: 'Please enter a directory for purpose foo!'.</div>
<div>"Maybe with property dictionary:"</div>
<div><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">FileDirectory resourceRequest</span></div>
<div><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;"> setProperty: #rootDirectory toValue: (FileDirectory on:
'c:');</span></div>
<div><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;"> signal: 'Please enter a directory for purpose foo!</span><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">'.</span><br>
</div>
<div><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;"><br>
</span></div>
<div><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">"Second example:"</span></div>
<div><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">SystemWindow class >> #resourceRequest</span></div>
<div><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;"> ^ CustomResourceRequest new</span></div>
<div><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;"> resourceString: 'window'; "for generating default messageText"</span></div>
<div><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;"> </span>uiBlock: [:request | UserChoiceRequest signal:
request messageText choices: (SystemWindow windowsIn: self currentWorld)]];</div>
<div> yourself</div>
<div><br>
</div>
<div>
<div style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">
"Usage:"</div>
<div>SystemWindow resourceRequest signal</div>
</div>
<div> ifNotNil: [:window | window comeToFront].</div>
<div><br>
</div>
<div>Or would this be too generic? Oh, what a fun to brainstorm a new object design :-)</div>
<div><br>
</div>
<div>Best,</div>
<div>Christoph</div>
</span></div>
</span></div>
<p></p>
<div id="Signature">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;">
<div name="divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Jakob Reschke <forums.jakob@resfarm.de><br>
<b>Gesendet:</b> Freitag, 28. Februar 2020 23:55:12<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] Separation of domain from UI in Squeak (was: 5.3 cannot rename subclasses of Error)</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr">Thinking about names and usage...<br>
<br>
UserRequest (base class)<br>
"Christoph proposed UserNotification, but notifications can be<br>
dismissed easily, confirmations or choices should not be"<br>
"Also Monticello and other packages already use *Request for the purpose"<br>
InputRequest "accurate, but too general?"<br>
Request "probably too general"<br>
"contrast with WebRequest, for example"<br>
"asynchronous/continuation style:"<br>
(InputRequestSubclass signal)<br>
eventually: [:response | ... ];<br>
then: [:response | ...];</div>
<div> ifRejected:/ifCancelled: [...].</div>
<div dir="ltr">"handling:"<br>
on: InputRequest do: [:request | request resume:/provide:/answer:/reply:/respond: whatever].<br>
<br>
UserInformation signalWith: 'Looks ok'<br>
"remains open whether this will be a modal popup or a message in some kind of notification area"<br>
on: UserInformation do: [:info | info resume/dismiss/accept/continue "ok"]<br>
"but it might also be information about (not for) a user"<br>
UserNotification signalWith: 'This makes more sense to me here for inform:'.<br>
"This is not really a request for information, only for acknowledgement"<br>
<br>
UserConfirmation signal .... "strange because here we want to request confirmation, not give one"<br>
UserConfirmation request: 'Does this look better?' "but signal is still inherited"<br>
on: UserConfirmation do: [:confirm | "strange again because the confirmation is yet to be given or denied"]<br>
UserConfirmRequest signal: 'This looks wordy even though it is already abbreviated'<br>
UserConfirmRequest request: 'Double double words'.<br>
UserConfirmRequest confirm: 'Double double, and the request shall confirm something??'<br>
"can be circumvented with a UserConfirmation factory but then signalling and handling use different class names"<br>
ConfirmationRequest signal: 'More letters, but looks nicer to me' trueChoice: #Agreed falseChoice: #Disagreed.<br>
on: ConfirmationRequest do: [:request | request resume:/respond:/reply:/answer:/choose: #Agreeable].<br>
on: ConfirmationRequest do: [:request | request confirm/deny].<br>
"ConfirmationRequested also possible, but not a noun -- different style"<br>
<br>
MultipleChoiceRequest signal: 'I think it is...' choices: #(Good Bad Done) labels: #(Yay Nay What)<br>
"unfortunately the class name is already taken in RefactoringTools"<br>
ChoiceRequest signal: 'shorter but maybe stranger?' choices: #(Yep Nope)<br>
MultiResponseRequest signal: 'I like...' responses: #(Cats Dogs Squeak You)<br>
"funnily the term 'multiple choice' implies a single answer from a set of many"<br>
ConfirmationRequest "or others (see above) could also be a subclass of multiple choice"<br>
ClassOrTraitRequest signal: 'Choose your request'.<br>
(ClassOrTraitRequest fromPattern: '*Class*Request') signal: 'Other ideas?'<br>
ClassifierRequest signal: 'Do you prefer UML-speak?'<br>
DirectoryRequest signal: 'What kinds of other requests to/from/by/with/... a directory are there?'<br>
DirectoryRequested signal: 'This might be less ambiguous'<br>
File/Font/String/Text/Password/Credentials/ObjectRequest/ed signal: 'Likewise' initialAnswer: whatever.<br>
"Makes me wonder whether UserRequest might imply that a user must be chosen<br>
instead of requesting something from users"<br>
XyzRequestedFromUser signal: 'More explicit purpose, but yet another naming style'<br>
"Can there be a protocol to request a certain kind of object from the user<br>
or would we really need one subclass for each kind?"<br>
Xyz requestFromUser: 'Choose your Xyz...'.<br>
on: Xyz input/userRequest do: [:request | ...].<br>
InputRequest signal: 'Choose your object' ofKind: Xyz.<br>
on: InputRequest do: [:request | (request acceptsA/n: Xyz) ifTrue: [...] ifFalse: [request pass]].<br>
...<br>
<br>
There is also ProgressInitiationException which does not have a nice name.<br>
It is not a request, but it already has displayProgress:* in UIManager<br>
as defaultAction.<br>
Alternative names:<br>
ProgressInitiation/ed<br>
ProgressStart/ed<br>
<br>
</div>
<br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Am Fr., 28. Feb. 2020 um 22:11 Uhr schrieb Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de">forums.jakob@resfarm.de</a>>:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
HI,<br>
<br>
Unless there is a good reason why handling ProvideAnswerNotification<br>
is not a good idea in scripted environments, I agree with Chris. I<br>
would prefer using the existing mechanism to introducing a strange<br>
synonym for Notification.<br>
<br>
Swapping the control flow, like Christoph proposed (user code signals<br>
the notification and defaultAction is the modal dialog), sounds ok to<br>
me too. It would also mean that user code does not have to access the<br>
UIManager singleton. On the other hand, it is less obvious whether<br>
something is meant to be a UI interaction if the names of the<br>
Notifications make the code strange to read. For the most basic cases,<br>
at least there still is Object>>inform:/confirm:/confirm:orCancel:.<br>
<br>
Kind regards,<br>
Jakob<br>
<br>
<br>
Am Mi., 26. Feb. 2020 um 22:41 Uhr schrieb Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>>:<br>
><br>
> Hi Marcel,<br>
><br>
>> > especially for this one tiny little thing of a modal alert when renaming classes?<br>
>><br>
>> 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.<br>
><br>
><br>
> Actually, they can.<br>
><br>
> "example 1"<br>
> [ self inform: 'stop everything and pay attention to me!' ] on: ProvideAnswerNotification do: [ : noti | noti resume ] "nil"<br>
><br>
> "example 2"<br>
> [UIManager default request: 'what is the answer?' initialAnswer: 'tell me now!' ] on: ProvideAnswerNotification do: [ : noti | noti resume: 42 ] "42 "<br>
><br>
> I assumed this is what the CI jobs were doing.. they're not?<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Best,<br>
> Chris<br>
><br>
>><br>
>><br>
>> > What happened to simply opening up a MessageSet on the references afterward?<br>
>><br>
>> Still there. Unrelated to this issue. See the end of Browser >> #renameClass.<br>
>><br>
>> > Say, why do we need a modal alert at all?<br>
>><br>
>> I agree, that extra check in Class >> #rename: might not be necessary and maybe moved to our refactoring tools.<br>
>><br>
>> Best,<br>
>> Marcel<br>
>><br>
>> Am 26.02.2020 00:21:48 schrieb Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>>:<br>
>><br>
>> -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?<br>
>><br>
>> - Chris<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On Tue, Feb 25, 2020 at 8:17 AM Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>> wrote:<br>
>>><br>
>>> Just "Notice"?<br>
>>><br>
>>> Am 25.02.2020 12:11:33 schrieb Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>>:<br>
>>><br>
>>><br>
>>><br>
>>> On Feb 25, 2020, at 1:40 AM, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>> wrote:<br>
>>><br>
>>> <br>
>>> Fixed. BUT: Please take a look at<br>
>>><br>
>>> Kernel-mt.1305<br>
>>> Tools-mt.941<br>
>>><br>
>>> We need a name! :-)<br>
>>><br>
>>><br>
>>> On second thoughts Notice might be a better name.<br>
>>><br>
>>><br>
>>> Best,<br>
>>> Marcel<br>
>>><br>
>>> Am 25.02.2020 10:11:22 schrieb Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>>:<br>
>>><br>
>>> > Maybe it is a sporadic issue?<br>
>>><br>
>>> It is! Related to the ProgressNotification which I accidentially catch in Browser >> #renameClass. I wanted to get the UI call out of Class >> #rename:.<br>
>>><br>
>>> That progress notification does not appear every time. Only above a certain threshold. That's why it appears to be sporadic.<br>
>>><br>
>>> Best,<br>
>>> Marcel<br>
>>><br>
>>> Am 25.02.2020 09:37:13 schrieb Thiede, Christoph <<a href="mailto:christoph.thiede@student.hpi.uni-potsdam.de" target="_blank">christoph.thiede@student.hpi.uni-potsdam.de</a>>:<br>
>>><br>
>>> I could reproduce it one single time ... Maybe it is a sporadic issue?<br>
>>><br>
>>><br>
>>> Best,<br>
>>><br>
>>> Christoph<br>
>>><br>
>>> ________________________________<br>
>>> Von: Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von Taeumel, Marcel<br>
>>> Gesendet: Dienstag, 25. Februar 2020 09:34:03<br>
>>> An: John Pfersich via Squeak-dev; Chris Muller<br>
>>> Betreff: Re: [squeak-dev] 5.3 cannot rename subclasses of Error<br>
>>><br>
>>> Hmm... I can reproduce the bug. Yet, calling "Error2 rename: #Error1" from a workspace works fine. Strange.<br>
>>><br>
>>> Best,<br>
>>> Marcel<br>
>>><br>
>>> Am 25.02.2020 09:16:13 schrieb Thiede, Christoph <<a href="mailto:christoph.thiede@student.hpi.uni-potsdam.de" target="_blank">christoph.thiede@student.hpi.uni-potsdam.de</a>>:<br>
>>><br>
>>> Hi Chris,<br>
>>><br>
>>><br>
>>> 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?<br>
>>><br>
>>><br>
>>> Best,<br>
>>><br>
>>> Christoph<br>
>>><br>
>>> ________________________________<br>
>>> Von: Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>><br>
>>> Gesendet: Dienstag, 25. Februar 2020 06:29:00<br>
>>> An: squeak dev<br>
>>> Betreff: [squeak-dev] 5.3 cannot rename subclasses of Error<br>
>>><br>
>>> In trunk / 5.3 RC.<br>
>>><br>
>>> - Make a subclass of Error called MyError1<br>
>>> - Make a subclass of Error called MyError2<br>
>>> - Delete MyError1<br>
>>> - Try to rename MyError2 to MyError1<br>
>>><br>
>>> The last step fails. No errors or debuggers, but the class is not renamed.<br>
>>><br>
>>> Works in 5.2.<br>
>>><br>
>>><br>
>>><br>
>><br>
><br>
</blockquote>
</div>
</div>
</div>
</body>
</html>