On Thu, Dec 20, 2018 at 11:33 AM karl ramberg <karlramberg at gmail.com> wrote:

> 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.
>

Exactly.  Try the following in a workspace with "auto declare variables
turned *off*)

a := Rectangle fromUser.
b := Rectangle fromUser.
c := [:e :f| e intersection: f. value: a value: b

What happens is we're prompted to declare a & b (and do so using "declare
as method temp").  Then we hit the syntax error from the missing ] after
"intersection: f".  The error message is inserted and our painstakingly
supplied variable declarations are lost in the ether.


> Best,
> Karl
>

Thanks Karl.


>
>
> On Thu, Dec 20, 2018 at 8:07 AM Marcel Taeumel <marcel.taeumel at hpi.de>
> wrote:
>
>> Hi Eliot,
>>
>> are you referring to this?
>>
>>
>> Best,
>> Marcel
>>
>> Am 20.12.2018 01:31:24 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>>
>> On Wed, Dec 19, 2018 at 1:46 PM karl ramberg <karlramberg at gmail.com>
>> wrote:
>>
>>> Also the two different dialogs that pop up for unknown variable when
>>> saving a method cause some dissonance.
>>> Two totally different dialogs for doing basically the same thing.
>>> See picture examples.
>>>
>>
>> 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?)
>>
>> Cheers,
>>> Karl
>>>
>>>
>>> On Wed, Dec 19, 2018 at 8:33 AM Marcel Taeumel <marcel.taeumel at hpi.de>
>>> wrote:
>>>
>>>> Hi, there.
>>>>
>>>> At the time of writing, we have:
>>>>
>>>> A) dialogs that close on an "outside click" (e.g., class serach in
>>>> system browser)
>>>>
>>>>
>>>> B) dialogs that insist on being treated on a globally exclusive level
>>>> (e.g., save before quit) -- wiggle wiggle :-)
>>>>
>>>>
>>>> C) dialogs/windows that are modally attached to their spawning window
>>>> (e.g., font chooser in text fields)
>>>>
>>>>
>>>> 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.
>>>>
>>>> Maybe we need another variation of dialogs:
>>>>
>>>> D) dialogs that are scoped to their spawning window AND restrict input
>>>> to that spawning window (effectively a variation of C)
>>>>
>>>> Best,
>>>> Marcel
>>>>
>>>> Am 19.12.2018 05:10:44 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>>>>
>>>> > On Dec 18, 2018, at 2:20 PM, Chris Muller wrote:
>>>> >
>>>> > Hi Tim,
>>>> >
>>>> >> Possibly related functionally but certainly by subject area -
>>>> >> 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.
>>>> >>
>>>> >> 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.
>>>> >
>>>> > I'm glad you put 'violated' in quotes like that, since there can be
>>>> > other scopes of modality than global. For example, it could extend
>>>> > from only the window which spawned it (the ideal), OR (going in the
>>>> > other direction to the extreme), what if opening up a FileDialog in
>>>> > your Squeak image not only prevented you from interacting with other
>>>> > Squeak windows but all other OS windows, too? (Impossible, I know,
>>>> > but a question for conceptual illustration..). IMO, any scope beyond
>>>> > the minimum scope seems arbitarily restricting.
>>>> >
>>>> > I think we should consider making all modal dialogs scoped only to the
>>>> > spawner.
>>>>
>>>> +10
>>>>
>>>> > As long as the dialog selection works and continues to
>>>> > process upon the selection, this sounds like a feature. Because even
>>>> > after the user has opened the dialog and navigated to the directory
>>>> > they want, if they find different file-names than they expected and
>>>> > need to go look elsewhere in the image to confirm, -- it seems
>>>> > unnecessary to make them cancel out and go through all of that again.
>>>> >
>>>> > Best,
>>>> > Chris
>>>> >
>>>> >
>>>> >> (I just noticed that using the halo does the same.)
>>>> >> Turn off 'generalizedYellowButtonMenu' in the preferences and you
>>>> don't get the (non-halo) problem.
>>>> >>
>>>> >>
>>>> >> tim
>>>> >> --
>>>> >> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>>>> >> Spell checkers at maximum! Fire!
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>>
>>>>
>>>>
>>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>>
>>
>>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20181220/f33dfa6c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 9342 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20181220/f33dfa6c/attachment-0001.png>