<body><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
Hi all! :-)<div><br></div><div>Here is a more general thought:</div><div><br><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">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.</span><br></div></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">The explicit use of a RemarkNotification (or similar) improves modularity by decoupling the mechanism from UI texts.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Just my two cents. :-) Let's work on that in 6.0alpha. Christoph (ct) has some interesting ideas in this regard.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel</span></div><div class="mb_sig"></div><blockquote class="history_container" type="cite" style="border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;">
<p style="color: #AAAAAA; margin-top: 10px;">Am 29.02.2020 18:48:22 schrieb Jakob Reschke <forums.jakob@resfarm.de>:</p><div style="font-family:Arial,Helvetica,sans-serif">Am Sa., 29. Feb. 2020 um 03:23 Uhr schrieb tim Rowledge <tim@rowledge.org>:<br>> 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.<br><br>Agreed. And in a catch-all handler, how do you know which details you<br>can access in the current handler invocation?<br><br>> 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?<br><br>If we had all these request exceptions Christoph and me are writing<br>about, I'd imagine the fallback handlers would sit in the Project<br>subclass. MorphicProject opens the UserDialogBoxMorph, MVCProject does<br>its equivalent thing, HeadlessProject must already know all the<br>answers or abort with an error, TerminalProject (sounds like the last<br>one before the program dies...) pops up the request with the imaginary<br>curses UI.<br><br>Also note that opening a debugger is a special case of all of this:<br>the debugger is the UI for the request of how to proceed in the event<br>of an error, warning or interrupt/halt/breakpoint.<br><br></tim@rowledge.org></div></blockquote>
</div></body>