search

squeak-smalltalk / squeak-object-memory

Issues and assets related to the Squeak object memory.
https://bugs.squeak.org
MIT License
11 stars 1 forks source link

#setAuthorInitials inconsistent behavior #45

Closed isCzech closed 2 years ago

isCzech commented 2 years ago

Two scenarios in a fresh image without author initials previously set:

A) invoke Extras -> Set author initials dialogue Now hit cancel and the dialogue disappears - this is ok.

B) make a change in a method and try to save -> Save author initials dialogue appears Now hit cancel and the dialogue reappears and it's impossible to get rid of it... ... unless you chose debug invocation from the dialogue window menu

Is this intentional? I'd expect the dialogue to disappear and method changes remain unsaved.

isCzech commented 2 years ago

Is this intentional?

(Marcel) Yes. The manual way to set author initials can easily be canceled. However, there are some places that rely on some initials to be set. So, calling #authorInitials will loop until until the user enters something. If you want to cancel those situations, you have to do, for example, CMD+Dot because you would also cancel any control flow that needs those credentials.

One possible change -- that needs to be discussed after the release -- would be to answer something like "unknown" if the user cancels the dialog. Yet, I would argue that that dialog MUST pop up again during the next request for #authorInitials.

I just thought cancelling the dialogue while NOT saving method changes would achieve the same result, i.e. no unauthored method changes.

(Marcel) Hmm... that would entail an inadvertent/hidden "CMD+Dot", right? Well, the user should be informed of such things. And we cannot know how deep the control flow currently is...

Christoph has ideas on how to improve user-input requests along with a proper design of Notifictions/Warnings. Maybe that would also cover this use case.

Closing; thanks to Marcel for the explanations above.