<div dir="ltr">Also the two different dialogs that pop up for unknown variable when saving a method cause some dissonance.<div>Two totally different dialogs for doing basically the same thing. </div><div>See picture examples.</div><div><br></div><div>Cheers,</div><div>Karl</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 19, 2018 at 8:33 AM Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de">marcel.taeumel@hpi.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_6032648804265350753__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)">
Hi, there.<div class="gmail-m_6032648804265350753mb_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:167c86731e4cb971f161" width="auto"></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:167c86731e5cb971f162" width="auto"></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:167c86731e5cb971f163" width="auto"></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="gmail-m_6032648804265350753history_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:rgb(170,170,170);margin-top:10px">Am 19.12.2018 05:10:44 schrieb Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif"><br>> On Dec 18, 2018, at 2:20 PM, Chris Muller <u></u> 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; <a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" target="_blank">http://www.rowledge.org/tim</a><br>>> Spell checkers at maximum! Fire!<br>>> <br>>> <br>>> <br>> <br><br><u></u></div></blockquote></div><br>
</blockquote></div>