<div dir="ltr">I think Elliot means if you save a method and go through setting all the variable names, and then encounter a error, you have to redo the selection of variable names again next time you save. The system forgets the selections when it encounter the error.<div><br></div><div>Best,</div><div>Karl</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 20, 2018 at 8:07 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_4196978521496036953__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)">
Hi Eliot,<div><br></div><div>are you referring to this?</div><div><br></div><div><img src="cid:167cd167568cb971f161" width="auto"></div><div><br></div><div>Best,</div><div>Marcel</div><div class="gmail-m_4196978521496036953mb_sig"></div>
<blockquote class="gmail-m_4196978521496036953history_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 20.12.2018 01:31:24 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">
<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr">On Wed, Dec 19, 2018 at 1:46 PM karl ramberg <<a href="mailto:karlramberg@gmail.com" target="_blank">karlramberg@gmail.com</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 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></blockquote><div><br></div><div>Plus IIRC that if there's a subsequent syntax error the variable declarations are lost. We really should do one edit and then automatically launch a recompile (or compile as much as we can and collect multiple undeclared together in one dialogue?)</div><div><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 dir="ltr"><div>Cheers,<br></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" target="_blank">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_4196978521496036953gmail-m_-8596669637713120149gmail-m_6032648804265350753__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)">
Hi, there.<div class="gmail-m_4196978521496036953gmail-m_-8596669637713120149gmail-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 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 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 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_4196978521496036953gmail-m_-8596669637713120149gmail-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>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_4196978521496036953gmail_signature"><div dir="ltr"><div><span style="font-size:10pt;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>
</div></blockquote></div><br>
</blockquote></div>