<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
Hi Karl,<div><br></div><div>yeah, some projects (or code) use "list chooser" for "yes/no" stuff. That's why we had to come up with this mixed versions of the dialog for list choosing. So: backwards compatibility.</div><div><br></div><div>Or maybe it is still a good idea to present buttons for smaller lists of stuff. Like we do now.</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></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 22:46:56 schrieb karl ramberg <karlramberg@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><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;min-width: 500px"><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"></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:167c86731e5cb971f162" 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:167c86731e5cb971f163" 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="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>
</div></blockquote></div>