Marcel gave the germane critique that such dialogs should preserve the possibility to replace the initial selection with a custom filter, without caring about any header, what's not possible with arguments at the moment.


Neither in the Trunk:

[cid:6c356e64-4ffd-44cf-aea3-25dd499999c7]

Nor with this changeset:

[cid:1108b59b-da0f-419b-bc50-6ac2961d5d78]


How could we solve this better?


How would you think about this solution?

[cid:6b87b5d2-d6dc-41a2-a3d2-0b10529ad6a1]

(Disclaimer, the screenshot is hacked via ObjectExplorer and no implementation exists at the moment. Ignore the ugly styling.)

The upper text field even could be read-only.


Question: Should we treat the input as method or block code? That is, should the answer 'true' be evaluated to 'true' or 'self'?

In general, I like to present the user a method-like dialog because this is more convenient for explaining the meaning of the arguments. On the contrary, the default return value of a method is self, not the latest statement.

Would it be misleading if the following "worked"?

[cid:5aee351b-531f-4d69-a026-ecae8923897a]


Call for opinions!


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Thiede, Christoph
Gesendet: Mittwoch, 22. Januar 2020 18:17:15
An: Squeak Dev
Betreff: [squeak-dev] Changeset: requestCode.cs


Hi all! :-)


This changeset extends the UIManager protocol by a set of methods for requesting code. It provides FillInTheCodeBlankMorph, a subclass of FillInTheBlankMorph which supports convenient code input. Convenience includes syntax highlighting, and, if installed, support for Autocompletion. This is how it looks in action:


[cid:2865a4e2-48fe-4d5f-ad76-d02203731d22]


This is a typical call of the new method #requestCode:cue: (diffed to the current version):


[cid:6b6885ae-7834-400d-b2ee-b39f9895f706]


Or another one:


[cid:00e50b6c-381f-47a4-8fa9-5148eaca123a]


In addition to the UIManager protocol and FillInTheCodeBlankMorph, the changeset patches three Trunk methods that can benefit from the change (Debugger>>#runUntil, Debugger>>#returnValue and MessageSet>>#filterToMessagesThat). Also, there is a small number of convenience methods I added to Compiler and CompilationCue.


As you may have noticed, I used CompilationCue to bundle all the compilation relevant data - i.e. receiver, environment, context -, because I did not like to define messages that take six or more arguments in the UIManager. However, I'm not sure whether CompilationCue is the right data class for this purpose? It also defines source and requestor which are not relevant here, and all its constructors require a source as well. However, we already have many places where receiver, environment and often also context are exchanged between objects: for Compiler, for SHStylerST80 and SHParser, and for Autocompletion. Would that be reasonable to introduce a separate data class for this purpose?


Note: Before merging this, let's talk about the UserNotification proposal<http://forum.world.st/Discussion-Warning-vs-Halt-or-quot-Why-is-a-warning-a-notification-quot-td5106457.html#a5106605> again. Provided that we decide to implement that in a visible future, I'd prefer not to define all these 5 versions of #requestCode:cue: on UIManager.


Looking forward to your feedback! :-)


Best,

Christoph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200215/3f055387/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 118741 bytes
Desc: pastedImage.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200215/3f055387/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 104047 bytes
Desc: pastedImage.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200215/3f055387/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 185838 bytes
Desc: pastedImage.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200215/3f055387/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 48053 bytes
Desc: pastedImage.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200215/3f055387/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 8117 bytes
Desc: pastedImage.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200215/3f055387/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 11868 bytes
Desc: pastedImage.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200215/3f055387/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 12832 bytes
Desc: pastedImage.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200215/3f055387/attachment-0013.png>