bug or feature - obscured modal dialogs?
Bryan Oakley
tk will let me pop up a modal dialog over a toplevel, then obscure that
dialog with "." thus locking up the UI in the case where the window
manager has been neutered and the user can't drag windows around.
Of course, one could argue that you should never write code that raises
"." when there's a dialog present (and/or you should give the user a
decent window manager), but whatyagonnado when you inherit someone
else's code? :-\
Anyway, at the end of this message is a small test (only tested on unix;
don't know what happens on windows). Save it to a file, run it, the
click on the "Press me" button in the smaller window. Once the modal
dialog is present click on the main window without pressing on the OK
button first.
On my box this causes "." to hide the modal dialog, seemingly locking up
the UI. Notice that because of the grab on the messagebox, the "Show
other window" button is dead.
I realize there are workarounds, but I'm wondering if this is a bug or
intentional behavior on tk's part.
bind . <1> {raise .}
button .b -text "Show other window" -command {raise .t}
pack .b
toplevel .t
button .t.b -text "Press me" -command {
tk_messageBox -message "Hello, world" -parent .t
}
pack .t.b
wm geometry . 400x400+10+10
wm geometry .t 200x200+50+50
update idletasks
raise .t
--
Bryan Oakley
http://www.tclscripting.com
Uwe Klein
> Anyway, at the end of this message is a small test (only tested on unix;
> don't know what happens on windows). Save it to a file, run it, the
> click on the "Press me" button in the smaller window. Once the modal
> dialog is present click on the main window without pressing on the OK
> button first.
>
> On my box this causes "." to hide the modal dialog, seemingly locking up
> the UI. Notice that because of the grab on the messagebox, the "Show
> other window" button is dead.
You have "raise on focus" active with your wm?
<script snip, nsip>
fvwm2: sloppy focus, no raise on focus. lower/raise flipflop for <1> on decoration.
I can raise . by way of clicking the decoration obscuring both .t and the messagesbox
the next click brings me back to the original ;-)
uwe
Ralf Fassel
| bind . <1> {raise .}
This will not get processed when the message box is up. Rather it is
your window manager's 'raise-on-click' setting which raises the {.}
window. On my desktop I have to click at the {.} title bar to make
the {.} window obscur the others. The net effect is the same, though.
| I realize there are workarounds, but I'm wondering if this is a bug
| or intentional behavior on tk's part.
Arguably, whenever a window issues a local or global grab, it should
not be possible to obscur this window, since otherwise the application
seems to hang. This happens a lot more on windows, where the OS
itself helpfully shifts the window stacking order around a lot, and
raise-on-click is the default.
No real solution to offer...
R'
Bryan Oakley
> Bryan Oakley wrote:
>
>> Anyway, at the end of this message is a small test (only tested on
>> unix; don't know what happens on windows). Save it to a file, run it,
>> the click on the "Press me" button in the smaller window. Once the
>> modal dialog is present click on the main window without pressing on
>> the OK button first.
>>
>> On my box this causes "." to hide the modal dialog, seemingly locking
>> up the UI. Notice that because of the grab on the messagebox, the
>> "Show other window" button is dead.
>
> You have "raise on focus" active with your wm?
I specifically have a binding that tells the main window to raise when
you click in ".".
Uwe Klein
Bryan Oakley wrote:
> Uwe Klein wrote:
>>
>> You have "raise on focus" active with your wm?
>
>
> I specifically have a binding that tells the main window to raise when
> you click in ".".
BUT that does not work for me(see prev. post),
i have to raise by clicking the decoration.
"bind . <1> {raise .}" IMHO is not the binding that is executed.
( test with debug statement in binding )
I think you have "raise on focus" _and_ "click to focus" active with your wm.
Thus your . window is raised by the wm !?
uwe
>
>
Bryan Oakley
While it is true that the window can be raised by the wm (and that's
what my original post demonstrates), there are other forces at play. I
should have done a better job representing the error.
This is a collaborative app that may be receiving data changes from
other apps automatically in the background. Unfortunately, those changes
might result in "raise ." being called while a modal window is
displayed. In that case, the application is causing "." to obscur a
modal dialog.
I can simulate this easy by doing 'after 30000 {raise .}" in a console
window, then sourcing the script I posted earlier, and clicking the
button to get the message box. I would have thought that raise wouldn't
raise "." above the message box, but it does (in the case where the
-parent of the messagebox is a toplevel that is a child of ".").
Ralf Fassel
| This is a collaborative app that may be receiving data changes from
| other apps automatically in the background. Unfortunately, those
| changes might result in "raise ." being called while a modal window
| is displayed. In that case, the application is causing "." to obscur
| a modal dialog.
If the toplevel had {.} as its parent (by issuing a wm transient
command, like the messagebox does for the -parent option), then the
'raise .' command would not raise {.} over the messagebox.
$ wish
toplevel .foo
wm transient .foo {.}
after 2000 raise {.} ; tk_messageBox -parent .foo
wm transient .foo {}
after 2000 raise {.} ; tk_messageBox -parent .foo
But I guess you can't control this for every toplevel in your app...
R'
Bryan Oakley
> * Bryan Oakley <oak...@bardo.clearlight.com>
> | This is a collaborative app that may be receiving data changes from
> | other apps automatically in the background. Unfortunately, those
> | changes might result in "raise ." being called while a modal window
> | is displayed. In that case, the application is causing "." to obscur
> | a modal dialog.
>
> If the toplevel had {.} as its parent (by issuing a wm transient
> command, like the messagebox does for the -parent option), then the
> 'raise .' command would not raise {.} over the messagebox.
Yes, I just came to that same conclusion when I realized our code wasn't
using 'wm transient' where it should. I think the current tk behavior is
correct in that situation.
Now that I realize our app isn't consistent with 'wm transient', the fix
is obvious.
>
> $ wish
> toplevel .foo
>
> wm transient .foo {.}
> after 2000 raise {.} ; tk_messageBox -parent .foo
>
> wm transient .foo {}
> after 2000 raise {.} ; tk_messageBox -parent .foo
>
> But I guess you can't control this for every toplevel in your app...
Actually, I can :-) now that I know what the true problem is.
Thanks for confirming my suspicions.