[squeak-dev] Another modal dialogue issue (was Re: inescapable modal dialog in trunk)

karl ramberg karlramberg at gmail.com
Thu Dec 20 19:32:35 UTC 2018


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.

Best,
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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20181220/4865a4fb/attachment.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/4865a4fb/attachment.png>


More information about the Squeak-dev mailing list