inescapable modal dialog in trunk

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

inescapable modal dialog in trunk

Chris Muller-3
1.  Make a method in a browser dirty.
2.  Click on another method.  Squeak displays, "Changes have not been
saved, is it okay to cancel those changes?"
3.  Click "No".
4.  Now try click anywhere else or do anything else in other windows
or the desktop.  Every click anywhere causes the dialog to reappear
until you say "Yes" or cancel the method changes.

Reply | Threaded
Open this post in threaded view
|

Re: inescapable modal dialog in trunk

K K Subbu
On 07/11/18 9:38 AM, Chris Muller wrote:
> 1.  Make a method in a browser dirty.
> 2.  Click on another method.  Squeak displays, "Changes have not been
> saved, is it okay to cancel those changes?"
> 3.  Click "No".
> 4.  Now try click anywhere else or do anything else in other windows
> or the desktop.  Every click anywhere causes the dialog to reappear
> until you say "Yes" or cancel the method changes.
Chris,

I am unable to reproduce this problem. In Step 4, I am able to open the
global menu or a workspace and continue working on other tasks without
having the modal dialog pop up.

I am on Squeak-5.2-18255 with Linux-64bit VM.

HTH .. Subbu

Reply | Threaded
Open this post in threaded view
|

Re: inescapable modal dialog in trunk

timrowledge


> On 2018-11-07, at 1:45 AM, K K Subbu <[hidden email]> wrote:
>
> On 07/11/18 9:38 AM, Chris Muller wrote:
>> 1.  Make a method in a browser dirty.
>> 2.  Click on another method.  Squeak displays, "Changes have not been
>> saved, is it okay to cancel those changes?"
>> 3.  Click "No".
>> 4.  Now try click anywhere else or do anything else in other windows
>> or the desktop.  Every click anywhere causes the dialog to reappear
>> until you say "Yes" or cancel the method changes.
> Chris,
>
> I am unable to reproduce this problem. In Step 4, I am able to open the global menu or a workspace and continue working on other tasks without having the modal dialog pop up.

Same thing on 5.2 32bit Pi - no problem with the dialogue at all.

Now an obvious thing is that my set of preferences is almost certainly very different to Chris' and some of those settings may have a relevant effect. I don't use smart splitters for example and maybe something related to that is interacting with the mouse presses; no idea.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- If she was any dumber, she'd be a green plant.



Reply | Threaded
Open this post in threaded view
|

Re: inescapable modal dialog in trunk

Chris Muller-3
Well, it appears the problem is present in the production 5.2 image
with stock Preference settings too!   :(

Here are exact steps to reproduce using the production 5.2 image:

1) launch Squeak5.2.

2) Click "Skip" to remove the "Welcome To Squeak" banner.  Close the
"Welcome To Squeak" window, too.

3) Click in the search bar in the upper right, type "asFloat" (without
quotes), and press [Return].  The window showing implementors is shown
with the first method selected.

4) Make it dirty.  Click in the text pane and insert a space.

5) Click on the second method.  Squeak displays, "Changes have not been
saved, is it okay to cancel those changes?"

6) Click "No".

7) Now try to click on the desktop.  The dialog keeps coming back.
On Wed, Nov 7, 2018 at 12:22 PM tim Rowledge <[hidden email]> wrote:

>
>
>
> > On 2018-11-07, at 1:45 AM, K K Subbu <[hidden email]> wrote:
> >
> > On 07/11/18 9:38 AM, Chris Muller wrote:
> >> 1.  Make a method in a browser dirty.
> >> 2.  Click on another method.  Squeak displays, "Changes have not been
> >> saved, is it okay to cancel those changes?"
> >> 3.  Click "No".
> >> 4.  Now try click anywhere else or do anything else in other windows
> >> or the desktop.  Every click anywhere causes the dialog to reappear
> >> until you say "Yes" or cancel the method changes.
> > Chris,
> >
> > I am unable to reproduce this problem. In Step 4, I am able to open the global menu or a workspace and continue working on other tasks without having the modal dialog pop up.
>
> Same thing on 5.2 32bit Pi - no problem with the dialogue at all.
>
> Now an obvious thing is that my set of preferences is almost certainly very different to Chris' and some of those settings may have a relevant effect. I don't use smart splitters for example and maybe something related to that is interacting with the mouse presses; no idea.
>
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful random insult:- If she was any dumber, she'd be a green plant.
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: inescapable modal dialog in trunk

Jakob Reschke-2
Confirmed. 5.2b 18225 Windows 64 bit.

Am Do., 8. Nov. 2018 um 22:29 Uhr schrieb Chris Muller <[hidden email]>:
Well, it appears the problem is present in the production 5.2 image
with stock Preference settings too!   :(

Here are exact steps to reproduce using the production 5.2 image:

1) launch Squeak5.2.

2) Click "Skip" to remove the "Welcome To Squeak" banner.  Close the
"Welcome To Squeak" window, too.

3) Click in the search bar in the upper right, type "asFloat" (without
quotes), and press [Return].  The window showing implementors is shown
with the first method selected.

4) Make it dirty.  Click in the text pane and insert a space.

5) Click on the second method.  Squeak displays, "Changes have not been
saved, is it okay to cancel those changes?"

6) Click "No".

7) Now try to click on the desktop.  The dialog keeps coming back.
On Wed, Nov 7, 2018 at 12:22 PM tim Rowledge <[hidden email]> wrote:
>
>
>
> > On 2018-11-07, at 1:45 AM, K K Subbu <[hidden email]> wrote:
> >
> > On 07/11/18 9:38 AM, Chris Muller wrote:
> >> 1.  Make a method in a browser dirty.
> >> 2.  Click on another method.  Squeak displays, "Changes have not been
> >> saved, is it okay to cancel those changes?"
> >> 3.  Click "No".
> >> 4.  Now try click anywhere else or do anything else in other windows
> >> or the desktop.  Every click anywhere causes the dialog to reappear
> >> until you say "Yes" or cancel the method changes.
> > Chris,
> >
> > I am unable to reproduce this problem. In Step 4, I am able to open the global menu or a workspace and continue working on other tasks without having the modal dialog pop up.
>
> Same thing on 5.2 32bit Pi - no problem with the dialogue at all.
>
> Now an obvious thing is that my set of preferences is almost certainly very different to Chris' and some of those settings may have a relevant effect. I don't use smart splitters for example and maybe something related to that is interacting with the mouse presses; no idea.
>
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful random insult:- If she was any dumber, she'd be a green plant.
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: inescapable modal dialog in trunk

timrowledge
In reply to this post by Chris Muller-3
Interesting data point, maybe, is that with Chris' recipe I get the problem as he describes it BUT if I open a full browser and make the method text dirty, click on another method and say 'no' to the dialogue I can then get the window menu, click on the method list (as opened by the menubar search) etc.

The only oddity I see is that once or twice clicking on the method list gives me the 'moving window around' frame and until I click again it wants to drag the window position. Hmm, trying to replicate that I think it might be an artefact of moving the mouse rapidly and clicking before stopping - I can get the same effect without the dialogue being involved. Maybe I'm triggering the drag action inadvertently.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Low on thinking gas.



Reply | Threaded
Open this post in threaded view
|

Re: inescapable modal dialog in trunk

K K Subbu
In reply to this post by Chris Muller-3
I can reproduce this in Squeak-5.2 Linux-64b.

Surprisingly, After step 7, if I right click in the text pane, I get a
strange menu that begins "Create New Service". If I now dismiss this
menu and then click on desktop, I am able to get a menu and everything
works normally, including getting the proper right-click menu in the
original text pane.

Weird .. Subbu

On 09/11/18 2:58 AM, Chris Muller wrote:

> Well, it appears the problem is present in the production 5.2 image
> with stock Preference settings too!   :(
>
> Here are exact steps to reproduce using the production 5.2 image:
>
> 1) launch Squeak5.2.
>
> 2) Click "Skip" to remove the "Welcome To Squeak" banner.  Close the
> "Welcome To Squeak" window, too.
>
> 3) Click in the search bar in the upper right, type "asFloat" (without
> quotes), and press [Return].  The window showing implementors is shown
> with the first method selected.
>
> 4) Make it dirty.  Click in the text pane and insert a space.
>
> 5) Click on the second method.  Squeak displays, "Changes have not been
> saved, is it okay to cancel those changes?"
>
> 6) Click "No".
>
> 7) Now try to click on the desktop.  The dialog keeps coming back.
> On Wed, Nov 7, 2018 at 12:22 PM tim Rowledge <[hidden email]> wrote:
>>
>>
>>
>>> On 2018-11-07, at 1:45 AM, K K Subbu <[hidden email]> wrote:
>>>
>>> On 07/11/18 9:38 AM, Chris Muller wrote:
>>>> 1.  Make a method in a browser dirty.
>>>> 2.  Click on another method.  Squeak displays, "Changes have not been
>>>> saved, is it okay to cancel those changes?"
>>>> 3.  Click "No".
>>>> 4.  Now try click anywhere else or do anything else in other windows
>>>> or the desktop.  Every click anywhere causes the dialog to reappear
>>>> until you say "Yes" or cancel the method changes.
>>> Chris,
>>>
>>> I am unable to reproduce this problem. In Step 4, I am able to open the global menu or a workspace and continue working on other tasks without having the modal dialog pop up.
>>
>> Same thing on 5.2 32bit Pi - no problem with the dialogue at all.
>>
>> Now an obvious thing is that my set of preferences is almost certainly very different to Chris' and some of those settings may have a relevant effect. I don't use smart splitters for example and maybe something related to that is interacting with the mouse presses; no idea.
>>
>>
>> tim
>> --
>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>> Useful random insult:- If she was any dumber, she'd be a green plant.
>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Another modal dialogue issue (was Re: inescapable modal dialog in trunk)

timrowledge
In reply to this post by timrowledge
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 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; [hidden email]; http://www.rowledge.org/tim
Spell checkers at maximum!  Fire!



Reply | Threaded
Open this post in threaded view
|

Re: Another modal dialogue issue (was Re: inescapable modal dialog in trunk)

marcel.taeumel
Hi, there!

This issue seems to be related to:

http://forum.world.st/The-Trunk-Morphic-mt-1439-mcz-td5077631.html (Morphic-mt.1439 MorphicExtras-mt.236 EToys-mt.329)

Let me use the upcoming Christmas vacation time to give this issue another shot. :-)

Best,
Marcel

Am 17.12.2018 20:20:40 schrieb tim Rowledge <[hidden email]>:

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 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; [hidden email]; http://www.rowledge.org/tim
Spell checkers at maximum! Fire!





Reply | Threaded
Open this post in threaded view
|

Re: Another modal dialogue issue (was Re: inescapable modal dialog in trunk)

marcel.taeumel
In the meantime, remember that CMD+Dot is a temporary workaround for such tenacious modal dialogs, because that issue is related to the HandMorph's mouse focus.

Best,
Marcel

Am 18.12.2018 09:07:59 schrieb Marcel Taeumel <[hidden email]>:

Hi, there!

This issue seems to be related to:

http://forum.world.st/The-Trunk-Morphic-mt-1439-mcz-td5077631.html (Morphic-mt.1439 MorphicExtras-mt.236 EToys-mt.329)

Let me use the upcoming Christmas vacation time to give this issue another shot. :-)

Best,
Marcel

Am 17.12.2018 20:20:40 schrieb tim Rowledge <[hidden email]>:

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 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; [hidden email]; http://www.rowledge.org/tim
Spell checkers at maximum! Fire!





Reply | Threaded
Open this post in threaded view
|

Re: Another modal dialogue issue (was Re: inescapable modal dialog in trunk)

Chris Muller-3
In reply to this post by timrowledge
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.  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; [hidden email]; http://www.rowledge.org/tim
> Spell checkers at maximum!  Fire!
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Another modal dialogue issue (was Re: inescapable modal dialog in trunk)

Eliot Miranda-2

> On Dec 18, 2018, at 2:20 PM, Chris Muller <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
>> Spell checkers at maximum!  Fire!
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Another modal dialogue issue (was Re: inescapable modal dialog in trunk)

marcel.taeumel
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 <[hidden email]>:


> 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; [hidden email]; http://www.rowledge.org/tim
>> Spell checkers at maximum! Fire!
>>
>>
>>
>



Reply | Threaded
Open this post in threaded view
|

Re: Another modal dialogue issue (was Re: inescapable modal dialog in trunk)

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

Cheers,
Karl


On Wed, Dec 19, 2018 at 8:33 AM Marcel Taeumel <[hidden email]> 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 <[hidden email]>:


> 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; [hidden email]; http://www.rowledge.org/tim
>> Spell checkers at maximum! Fire!
>>
>>
>>
>





DialogWindow.png (10K) Download Attachment
PluggableDialogWindow.png (18K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Another modal dialogue issue (was Re: inescapable modal dialog in trunk)

Eliot Miranda-2

On Wed, Dec 19, 2018 at 1:46 PM karl ramberg <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:


> 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; [hidden email]; http://www.rowledge.org/tim
>> Spell checkers at maximum! Fire!
>>
>>
>>
>





--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Another modal dialogue issue (was Re: inescapable modal dialog in trunk)

marcel.taeumel
In reply to this post by Karl Ramberg
Hi Karl,

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.

Or maybe it is still a good idea to present buttons for smaller lists of stuff. Like we do now.

Best,
Marcel

Am 19.12.2018 22:46:56 schrieb karl ramberg <[hidden email]>:

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.

Cheers,
Karl


On Wed, Dec 19, 2018 at 8:33 AM Marcel Taeumel <[hidden email]> 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 <[hidden email]>:


> 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; [hidden email]; http://www.rowledge.org/tim
>> Spell checkers at maximum! Fire!
>>
>>
>>
>




Reply | Threaded
Open this post in threaded view
|

Re: Another modal dialogue issue (was Re: inescapable modal dialog in trunk)

marcel.taeumel
In reply to this post by Eliot Miranda-2
Hi Eliot,

are you referring to this?


Best,
Marcel

Am 20.12.2018 01:31:24 schrieb Eliot Miranda <[hidden email]>:


On Wed, Dec 19, 2018 at 1:46 PM karl ramberg <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:


> 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; [hidden email]; http://www.rowledge.org/tim
>> Spell checkers at maximum! Fire!
>>
>>
>>
>





--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Another modal dialogue issue (was Re: inescapable modal dialog in trunk)

Karl Ramberg
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 <[hidden email]> wrote:
Hi Eliot,

are you referring to this?


Best,
Marcel

Am 20.12.2018 01:31:24 schrieb Eliot Miranda <[hidden email]>:


On Wed, Dec 19, 2018 at 1:46 PM karl ramberg <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:


> 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; [hidden email]; http://www.rowledge.org/tim
>> Spell checkers at maximum! Fire!
>>
>>
>>
>





--
_,,,^..^,,,_
best, Eliot



Reply | Threaded
Open this post in threaded view
|

Re: Another modal dialogue issue (was Re: inescapable modal dialog in trunk)

Karl Ramberg
In reply to this post by marcel.taeumel
I think list chooser is probably the most flexible.
But at least sticking to one kind of dialog would be nice. 
Like it is now is really confusing.

Best,
Karl




On Thu, Dec 20, 2018 at 8:05 AM Marcel Taeumel <[hidden email]> wrote:
Hi Karl,

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.

Or maybe it is still a good idea to present buttons for smaller lists of stuff. Like we do now.

Best,
Marcel

Am 19.12.2018 22:46:56 schrieb karl ramberg <[hidden email]>:

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.

Cheers,
Karl


On Wed, Dec 19, 2018 at 8:33 AM Marcel Taeumel <[hidden email]> 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 <[hidden email]>:


> 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; [hidden email]; http://www.rowledge.org/tim
>> Spell checkers at maximum! Fire!
>>
>>
>>
>





Reply | Threaded
Open this post in threaded view
|

Re: Another modal dialogue issue (was Re: inescapable modal dialog in trunk)

Eliot Miranda-2
In reply to this post by Karl Ramberg


On Thu, Dec 20, 2018 at 11:33 AM karl ramberg <[hidden email]> 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 <[hidden email]> wrote:
Hi Eliot,

are you referring to this?


Best,
Marcel

Am 20.12.2018 01:31:24 schrieb Eliot Miranda <[hidden email]>:


On Wed, Dec 19, 2018 at 1:46 PM karl ramberg <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:


> 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; [hidden email]; http://www.rowledge.org/tim
>> Spell checkers at maximum! Fire!
>>
>>
>>
>





--
_,,,^..^,,,_
best, Eliot




--
_,,,^..^,,,_
best, Eliot