<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
                                        
                                        
                                            
                                        
                                        
                                        Hi, there.<div class="mb_sig"></div>
                                        
                                        <div><br></div><div>At the time of writing, we have:</div><div><br></div><div>A) dialogs that close on an "outside click" (e.g., class serach in system browser)</div><div><br></div><div><img src="cid:0f310dd1-232b-4c28-a7e2-1f3c3c21207a" width="auto"></img></div><div><br></div><div>B) dialogs that insist on being treated on a globally exclusive level (e.g., save before quit) -- wiggle wiggle :-)</div><div><br></div><div><img src="cid:a6b83aaf-25c4-48b6-ad42-f3f3d577c196" width="auto"></img></div><div><br></div><div>C) dialogs/windows that are modally attached to their spawning window (e.g., font chooser in text fields)</div><div><br></div><div><img src="cid:75898d9d-55ec-4c34-8876-5c34a6d0fabf" width="auto"></img></div><div><br></div><div>All these variations have their pros and cons. Yet, we cannot reduce all scenarios to only one version. Programmers should refrain from using B too often. Only for system-wide interruptions. A and C are what seems to be less distracting for the user.</div><div><br></div><div>Maybe we need another variation of dialogs:</div><div><br></div><div>D) dialogs that are scoped to their spawning window AND restrict input to that spawning window (effectively a variation of C)</div><div><br></div><div>Best,</div><div>Marcel</div><div><br></div><blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 19.12.2018 05:10:44 schrieb Eliot Miranda <eliot.miranda@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif"><br>> On Dec 18, 2018, at 2:20 PM, Chris Muller <asqueaker@gmail.com> wrote:<br>> <br>> Hi Tim,<br>> <br>>> Possibly related functionally but certainly by subject area -<br>>> the modal dialogues I build for the file chooser etc are 'violated' by a yellowbuttonmenu IF you haven't turned off yellowbutton menus. Not noticed before because my normal preferences do just that; this time I tried some stuff in a very vanilla image and spotted the problem.<br>>> <br>>> Open a file chooser. cClick about a bit to make sure it is live. Click yellow button; you can now wander off and click in other windows - you've killed the modal nature of the dialog. You can 'return' by simply clicking in the dialog again.<br>> <br>> I'm glad you put 'violated' in quotes like that, since there can be<br>> other scopes of modality than global.  For example, it could extend<br>> from only the window which spawned it (the ideal), OR (going in the<br>> other direction to the extreme), what if opening up a FileDialog in<br>> your Squeak image not only prevented you from interacting with other<br>> Squeak windows but all other OS windows, too?   (Impossible, I know,<br>> but a question for conceptual illustration..).   IMO, any scope beyond<br>> the minimum scope seems arbitarily restricting.<br>> <br>> I think we should consider making all modal dialogs scoped only to the<br>> spawner.  <br><br>+10<br><br>> As long as the dialog selection works and continues to<br>> process upon the selection, this sounds like a feature.  Because even<br>> after the user has opened the dialog and navigated to the directory<br>> they want, if they find different file-names than they expected and<br>> need to go look elsewhere in the image to confirm, -- it seems<br>> unnecessary to make them cancel out and go through all of that again.<br>> <br>> Best,<br>>  Chris<br>> <br>> <br>>> (I just noticed that using the halo does the same.)<br>>> Turn off 'generalizedYellowButtonMenu' in the preferences and you don't get the (non-halo) problem.<br>>> <br>>> <br>>> tim<br>>> --<br>>> tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim<br>>> Spell checkers at maximum!  Fire!<br>>> <br>>> <br>>> <br>> <br><br></asqueaker@gmail.com></div></blockquote></div>