We could define even more of these fallback methods. However, I'm not sure how we should choose the kernel methods we could fall back to:

For example, in #multilineRequest:..., we could fall back to #request:.... However, wouldn't it be easier for a lazy subclass implementor that only wants to implement a single one method if we fell back just the other way around and called #multilineRequest:... from #request:...? On the other hand, multiline requests might be a rather rare use case.

To demonstrate the relevance of this design problem, I would like to ask the same question for #confirm:title: vs. #confirm:title:trueChoice:falseChoice:. Actually, the short version is only an edge case of the long version. But would we really want to require each possible subclass to implement the long and complex version?


And just another question:

Would it be okay to add further fallbacks for #chooseDirectory:from: and the #chooseFileMatching: versions? Basically, they can be implemented via simple #request: ("enter a filepath"), but to ensure that the path is valid, we would need to depend on Files. At the moment, we require each concrete subclass of UIManager to depend so.


Tricky questions (at least for me) ... I am looking forward to your help!


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von commits at source.squeak.org <commits at source.squeak.org>
Gesendet: Freitag, 24. Januar 2020 18:34:44
An: squeak-dev at lists.squeakfoundation.org
Betreff: [squeak-dev] The Inbox: ToolBuilder-Kernel-ct.135.mcz

Christoph Thiede uploaded a new version of ToolBuilder-Kernel to project The Inbox:
http://source.squeak.org/inbox/ToolBuilder-Kernel-ct.135.mcz

==================== Summary ====================

Name: ToolBuilder-Kernel-ct.135
Author: ct
Time: 24 January 2020, 6:34:43.604574 pm
UUID: 3ec2613e-56d3-2d41-b5c3-799a66a986e9
Ancestors: ToolBuilder-Kernel-mt.134

Provides fallback implementations for some UIManager messages

=============== Diff against ToolBuilder-Kernel-mt.134 ===============

Item was changed:
  ----- Method: UIManager>>chooseFrom:values:lines:title: (in category 'ui requests') -----
  chooseFrom: labelList values: valueList lines: linesArray title: aString
+        "Choose an item from the given list. Answer the corresponding value."
+        | result |
+        result := self chooseFrom: labelList lines: linesArray title: aString.
+        (result isNil or: [result isZero]) ifTrue: [^ nil].
+        ^ valueList at: result!
-        "Choose an item from the given list. Answer the selected item."
-        ^self subclassResponsibility!

Item was changed:
  ----- Method: UIManager>>confirm:orCancel: (in category 'ui requests') -----
  confirm: aString orCancel: cancelBlock
+        "Put up a yes/no/cancel menu with caption aString. Answer true if the response is yes, false if no. If cancel is chosen, evaluate cancelBlock. This is a modal question--the user must respond yes or no."
+        ^ (self confirm: aString)
+                ifFalse: [cancelBlock value];
+                yourself!
-        "Put up a yes/no/cancel menu with caption aString. Answer true if
-        the response is yes, false if no. If cancel is chosen, evaluate
-        cancelBlock. This is a modal question--the user must respond yes or no."
-        ^self subclassResponsibility!

Item was changed:
  ----- Method: UIManager>>confirm:orCancel:title: (in category 'ui requests') -----
  confirm: aString orCancel: cancelBlock title: titleString
+        "Put up a yes/no/cancel menu with caption aString, and titleString to label the dialog. Answer true if the response is yes, false if no. If cancel is chosen, evaluate cancelBlock. This is a modal question--the user must respond yes or no."
+        ^ (self confirm: aString title: titleString)
+                ifFalse: [cancelBlock value];
+                yourself!
-        "Put up a yes/no/cancel menu with caption aString, and titleString to label the dialog.
-        Answer true if  the response is yes, false if no. If cancel is chosen, evaluate cancelBlock.
-        This is a modal question--the user must respond yes or no."
-        ^self subclassResponsibility!

Item was changed:
  ----- Method: UIManager>>request:initialAnswer:centerAt: (in category 'ui requests - text') -----
  request: queryString initialAnswer: defaultAnswer centerAt: aPoint
+        "Create an instance of me whose question is queryString with the given initial answer. Invoke it centered at the given point, and answer the string the user accepts. Answer the empty string if the user cancels."
-        "Create an instance of me whose question is queryString with the given
-        initial answer. Invoke it centered at the given point, and answer the
-        string the user accepts. Answer the empty string if the user cancels."

+        ^ self request: queryString initialAnswer: defaultAnswer!
-        ^self subclassResponsibility!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200124/10c6839a/attachment.html>