Hi All,
would it be easy to modify modal dialog box interaction to allow closing the "parent window" of a dialog while in the modal dialog? In the VMSimulator I use a modal dialog to prompt the user for input to evaluate, to test the sim. Often I simply want to stop after the first expression and so wish to diss,iss the entire simulation omg the second modal dialog. Bit I'm always forced to select "don't be modal" before I can close the thing. It;'s a little annoying. _,,,^..^,,,_ best, Eliot |
Hi Eliot,
I did not ever work with the VM simulator, but from what you say, I guess that your modal dialog might simply lack a third button labeled "Quit"? In general, to me, the idea of modal windows appears to require an immediate user response that precedes any different user interactions with the notifying view. If this assumption is violated, many models might show bad behavior.* I would rather prefer not to change this behavior. :)
* For an example, do-it |x| (sic, just three characters) in a workspace. Disable modal exclusivity of the appearing Unused Variable dialog, clear the Workspace and then answer the dialog. Of course, you will get an internal compiler error ...
Best, Christoph Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Freitag, 10. Januar 2020 00:58:18 An: The general-purpose Squeak developers list Betreff: [squeak-dev] Closing modal dialogs... Hi All,
would it be easy to modify modal dialog box interaction to allow closing the "parent window" of a dialog while in the modal dialog? In the VMSimulator I use a modal dialog to prompt the user for input to evaluate, to test the sim. Often I simply
want to stop after the first expression and so wish to diss,iss the entire simulation omg the second modal dialog. Bit I'm always forced to select "don't be modal" before I can close the thing. It;'s a little annoying.
_,,,^..^,,,_
best, Eliot
Carpe Squeak!
|
Hi Christoph, On Fri, Jan 10, 2020 at 4:35 AM Thiede, Christoph <[hidden email]> wrote:
That doesn't work for me because the modal dialog emerges from a subcomponent (the FilePlugin) not from the VM level itself. It is from a plugin in the VM, and making that dialog able to reach out and smite the entire VM feels like working out-of-bounds.
Would you? Why wouldn't you discard the entire compilation continuation? That is what I would expect t. So killing the dialog effectively kills the process up to the point of invoking the Unused Variable dialog. It would not allow computation to continue. What should happen is the current process is terminated, a new UI process created, and the user be free to interact with the UI afresh.
|
Hi Eliot,
> Would you? Why wouldn't you discard the entire compilation continuation? That is what I would expect t. So killing the dialog effectively kills the process up to the point of invoking the Unused Variable dialog.
I don't think that toggling the "be modally exclusive" box should be meant as killing the process. Otherwise, we should really rename it ... I would rather think of this feature as a fork.
(Moreover, I never was really happy with the way to pause the UI process ... In particular, MC modal dialogs, which are not exclusive, don't need to decorate the whole UI process. Why can't these things work with the observer pattern instead?)
> That doesn't work for me because the modal dialog emerges from a subcomponent (the FilePlugin) not from the VM level itself. It is from a plugin in the VM, and making that dialog able to reach out and smite the entire VM feels like working out-of-bounds. I may have expressed myself inaccurately: Why is your plugin not able to do something like
UIManager default chooseFrom: #('Yes' 'No' 'Quit this operations')
?
However, in my humble opinion, adding an extra button for closing the parent window of a modal dialog sounds kind of insular solution to me. In most scenarios, modal dialogs come without any window. In other scenarios, a window might control multiple processes. What if the "parent window" is detected to be a debugger debugging a process that spawns a modal dialog? Would you then close the debugger? Other opinions? :-)
Best, Christoph Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Freitag, 10. Januar 2020 19:02:45 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Closing modal dialogs... Hi Christoph,
On Fri, Jan 10, 2020 at 4:35 AM Thiede, Christoph <[hidden email]> wrote:
That doesn't work for me because the modal dialog emerges from a subcomponent (the FilePlugin) not from the VM level itself. It is from a plugin in the VM, and making that dialog able to reach out and smite the entire VM feels like working out-of-bounds.
Would you? Why wouldn't you discard the entire compilation continuation? That is what I would expect t. So killing the dialog effectively kills the process up to the point of invoking the Unused Variable dialog. It would not allow computation to continue.
What should happen is the current process is terminated, a new UI process created, and the user be free to interact with the UI afresh.
Carpe Squeak!
|
Thiede, Christoph <[hidden email]> schrieb am Mo., 13. Jan. 2020, 13:10:
Promises can also be nice. Allows you to write the continuation next to the invocation. |
In reply to this post by Eliot Miranda-2
Do I understand correctly that your simulation prompts you endlessly and you want a "power button" to shut it down? Eliot Miranda <[hidden email]> schrieb am Fr., 10. Jan. 2020, 00:58:
|
Hi Jakob, On Jan 13, 2020, at 11:24 AM, Jakob Reschke <[hidden email]> wrote:
The root window contains the image of the simulation’s display bitmap, a transcript etc, and a pop up menu from which one can derive several other windows (processor, stack frame and object inspectors, etc). If so chosen the simulator can run an image could gaining a REPL which prompts for an expression to evaluate, this is the modal dialog prompt. When the root window is closed, all attendant inspectors and any debugger are closed also. I would like to be able to close the root window by clicking its close button while the the modal dialogue is displaying to be able to shut down everything. As it is I have to toggle the dialog into non-exclusivity before I can do so. It’s mildly annoying (and new behaviour as of a few years ago).
|
Sounds to me like you don't really want a modal dialog :-) How would the control flow of the code invoking the dialog look like when "something" interrupts and closes it? Modal invocations provide a synchronous interface for user input after all. If a window had to terminate a process to be able to quit an application that displays a modal dialog, I would think some abstraction is leaking. Anyway as a precondition modal dialogs would need to know their parent windows or morphs, or the other way around. I don't think they currently do. Our modal dialogs currently affect the whole world (unlike in native applications), don't they? Eliot Miranda <[hidden email]> schrieb am Di., 14. Jan. 2020, 03:00:
|
Free forum by Nabble | Edit this page |