Smalltalk › Squeak › Squeak - Dev

ProvideAnswerNotification and UIManager

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

patrick.rein

ProvideAnswerNotification and UIManager

Hi everyone,

some of you might remember that I proposed a changeset for refactoring the signaling and handling of ProvideAnswerNotification (ProvideAnswerNotification and UIManager ( http://forum.world.st/ProvideAnswerNotification-and-UIManager-td5081488.html) and original text below). David already looked at it briefly and I would like to merge the changes in the near future (before it gets lost), so I would like to ask for other opinions before adding it. :)

Bests
Patrick

Hi everyone,

recently I noticed that the method BlockClosure>>valueSupplyingAnswer: (and related ones) do
not work on all method of UIManager. When I looked into the issue I noticed that the signaling of
ProvideAnswerNotification is not done in the UIManagers but in the classes implementing the
actual user interfaces for the corresponding queries (e.g. MenuMorph and PopUpMenu). This
scattered the ProvideAnswerNotification logic throughout different packages and classes and
might have lead to the oversights.

The attached changeset is a refactoring of this mechanism which moves the corresponding
logic into the UIManagers. Unfortunately, this required some code duplication but at least it is
contained with the UIManager. On the plus side the code is contained in the UIManagers and
all methods should be covered now.

As I am not very familiar with the original intend and responsibilities of the UIManagers I wanted
to ask whether anyone has any thoughts on that change.

Thanks and bests
Patrick
["ProvideAnswerNotification.2.cs"]

ProvideAnswerNotification.2.cs (46K) Download Attachment

David T. Lewis

Re: ProvideAnswerNotification and UIManager

+1 for moving it to trunk, and thanks for waiting until after the 5.2 release was done.

The changes load without problems in 5.2, work well, and they have good unit test coverage.

These updates let a UIManager be responsible for dispatching the user interface
requests, which is exactly the right thing to do. See class comment:

UIManager is a dispatcher for various user interface requests, such as
menu and dialog interactions. An instance of UIManager is associated with
each Project to implement the appropriate functions for Morphic, MVC or
other user interfaces.

Thanks,
Dave

On Thu, Oct 18, 2018 at 05:56:28PM +0100, [hidden email] wrote:

> Hi everyone,
>
> some of you might remember that I proposed a changeset for refactoring the signaling and handling of ProvideAnswerNotification (ProvideAnswerNotification and UIManager ( http://forum.world.st/ProvideAnswerNotification-and-UIManager-td5081488.html) and original text below). David already looked at it briefly and I would like to merge the changes in the near future (before it gets lost), so I would like to ask for other opinions before adding it. :)
>
> Bests
> Patrick
>
> Hi everyone,
>
> recently I noticed that the method BlockClosure>>valueSupplyingAnswer: (and related ones) do
> not work on all method of UIManager. When I looked into the issue I noticed that the signaling of
> ProvideAnswerNotification is not done in the UIManagers but in the classes implementing the
> actual user interfaces for the corresponding queries (e.g. MenuMorph and PopUpMenu). This
> scattered the ProvideAnswerNotification logic throughout different packages and classes and
> might have lead to the oversights.
>
> The attached changeset is a refactoring of this mechanism which moves the corresponding
> logic into the UIManagers. Unfortunately, this required some code duplication but at least it is
> contained with the UIManager. On the plus side the code is contained in the UIManagers and
> all methods should be covered now.
>
> As I am not very familiar with the original intend and responsibilities of the UIManagers I wanted
> to ask whether anyone has any thoughts on that change.
>
> Thanks and bests
> Patrick
> ["ProvideAnswerNotification.2.cs"]