COMMENTS REQUESTED: behavior of tk_dialog

[Ralph Geier]

IMHO changing the behavior of tk_dialog (-> not to make the dialog
a transient for its parent) was not a good idea:

If the dialog is obscured from other windows (e.g. if someone
doesn't reply immediately but does other things), the application
doesn't respond -due to the grab-, but you don't now why, because
the dialog isn't raised together with its parent.

May be an adjustable behavior (optional parameter to tk_dialog,
global variable, ...) meets all needs?

Any comments?

Ralph

--
Ralph Geier Email : Ralph...@mch.sni.de
Siemens Nixdorf AG Tel. : 49-89-636-44894

[Andreas Leitgeb]

Ralph Geier (ge...@ALTAIR.mch.sni.de) wrote:
: IMHO changing the behavior of tk_dialog (-> not to make the dialog

: a transient for its parent) was not a good idea:

: If the dialog is obscured from other windows (e.g. if someone
: doesn't reply immediately but does other things), the application
: doesn't respond -due to the grab-, but you don't now why, because
: the dialog isn't raised together with its parent.

: May be an adjustable behavior (optional parameter to tk_dialog,
: global variable, ...) meets all needs?

i second that, and i want to state another tk_dialog-problem:
tk_dialog uses "tkwait variable" to check, when to return.
(probably it was assumed, that the only way to kill the window is
to click a button (or to xkill the whole app)

but: if the tk_dialog is created as a child of some other toplevel,
then it is still possible to normally quit the other toplevel, which
will also destroy the tk_dialog, but *not* touch the tkwait variable !!!!
when this happens, it seems all ok, until i quit the main window (".");
the tkwait is then still pending, and the application doesn't exit.