Tk Source Code

# The following demonstrates the problem;
# enter interactively at the wish prompt

toplevel .t ; wm transient .t .
wm withdraw .t

# Here, .t is withdrawn.
wm iconify .   ;# Or use window manager controls ...
wm deiconify . ;# ... ditto

# .t reappears!  This should not happen

--

This happens on Unix/X11.

Jeff reports that it also happens on Windows, and also
affects the dropdown listbox for comboboxes.

Logged In: YES 
user_id=90858

I checked in a patch on 2002-06-22 that fixes up
the tests so they pass under Windows. I will file
a new bug for the new crash I found. It is not really
related to these changes.

Logged In: YES 
user_id=90858

I just ran the test cases under Win32 and I am
seeing crashes and failed tests. Opening this
bug again.

Logged In: YES 
user_id=90858

Committed on 2002-06-21.

Logged In: YES 
user_id=72656

fixes the problems on Windows.  Please commit.

Logged In: YES 
user_id=68433

Patch looks good to me.   Tested under 4DWM and
Enlightenment.  

(From the Tcl'ers Chat): Jeff says to go ahead and commit
the patch, and do it on Windows too.

Thanks.

File Deleted - 25597: 



File Added - 25598: trans_withdraw.patch

Logged In: YES 
user_id=90858

Here is a new version of the patch that supports
both X and Win32. Care to take another shot at it?
The tests pass for me under X (RedHat 6.2).

Logged In: YES 
user_id=72656

I'm not really seeing a problem before or after the patch on X 
(using Exceed).  I do still see it on Windows though.

File Added - 25597: unix_trans.patch

Logged In: YES 
user_id=90858

I have attached a patch and tests for the X impl,
could you give it a quick test to see if it fixes
the BWidget or other related problems?

Logged In: YES 
user_id=72656

OK, so the essence is that Mo is trying to make the 4DWM 
behavior the standard Tk behavior across platforms, which we 
all believe is a Good Thing.  The only thing then that needs 
fixing is the maintaining of the previous state of transients on 
resurrection of the master.  Mo is working on this as we 
type ...

Logged In: YES 
user_id=68433

> Also, the X implementation would withdraw the transient
> if the master was iconified (but only by the user,
> it would not do this if the wm iconify command was used).

This was not done internally by Tk itself; it would have
been handled by the window manager.

Under 4DWM, [wm iconify $toplevel] _does_ cause all
transients to be iconified (actually they appear withdrawn,
but [wm state] says they're iconic).  On transitioning back
to 'normal' via [wm state], [wm deiconify], or user
interaction, 4DWM also remaps the transients.

The same happens under Enlightenment (at least initially).

Where the trouble comes in -- at least on 4DWM and E, can
test others if needed -- is when the master is withdrawn.
Under 4DWM, this withdraws both the master and transients,
but subsequently deiconifying the master does not remap the
transients.  

Under E, the transients stay mapped.  After remapping the
master, E appears to ignore the transient relationship
altogether (though they're still decorated as transients)
until the transient is withdrawn and remapped.

The ICCCM is (as usual) completely unhelpful here.  AFAICT,
neither 4DWM nor E is actually doing anything wrong; the
ICCCM just fails to specify what they should be doing.

Logged In: YES 
user_id=90858

I will work on a patch to add back the old
behavior tonight. Stay tuned.

Logged In: YES 
user_id=72656

> The old Win32 implementation did not work like that.
> It would withdraw a transient if the master was
> withdrawn.

OK, I believe this is a valid fix, it's just the change in the 
reverse behavior is a problem.  The transient windows need to 
maintain their state of withdrawn if they were already 
withdrawn or iconified before the master.  Mo's comments 
remind me vaguely that we've looked at this before.

Logged In: YES 
user_id=90858

> The key problem is that this new behavior is
> significantly  different from the old behavior.
> Transience is about look of the window, and it's
> relationship to it's parent when visible - 
> but I think grouping is separate.

The old Win32 implementation did not work like that.
It would withdraw a transient if the master was
withdrawn. This difference was what got me started
down the path of getting the functionality of transients
tested and working the same way on both platforms.
Also, the X implementation would withdraw the transient
if the master was iconified (but only by the user,
it would not do this if the wm iconify command was used).

Logged In: YES 
user_id=72656

See the problem with the following code:

package require BWidget
foreach w {.a .b .c .d .e .f} {
   pack [ComboBox $w -values {a b c d e f g h}]
}

now just select a value for each box, iconify and redisplay.  
All the comboboxes will redisplay as well.

Logged In: YES 
user_id=72656

The key problem is that this new behavior is significantly 
different from the old behavior.  Transience is about look of 
the window, and it's relationship to it's parent when visible - 
but I think grouping is separate.

The real problem is that this will break lots of existent code.  
It is/was common practice to create a toplevel once (transient 
or not), and then instead of recreating it each time, withdraw 
and deiconify as appropriate.  This created a much snappier 
feel to an app.  Now this is no longer valid.

You can see the really bad effect with bwidgets, which uses 
the transient feature for the dropdown combos and other 
similar items (that are also overrideredirect).  Iwidgets may do 
the same.  Now you iconify and reshow, and a bunch of 
toplevels show up with it.

Logged In: YES 
user_id=90858

No, I am not talking about the wm group command.
A transient window is a group of 2 in the sense
that it is meant to follow the master. When the
master is mapped, it should be mapped. When the
master is withdrawn, it should be withdrawn.

The special case of withdrawing the transient and
then toggling the state of the master was not
explicitly handled by my patch. If you two
are sure you want this special case added
back, I will write up a patch for it.

I am not sure what kind of "reference" you
are looking for. There was certainly nothing
helpful in the old man page for the transient
command. There was no rhyme nor reason to
the differences in the Win32 and X
implementations of this transient functionality.
The Windows implementation was certainly not
just a "hint" to the WM.

Logged In: YES 
user_id=72656

BTW, I think what Mo is thinking about is "grouping" - that 
was intended to have those characteristics, but transient and 
grouping (wm transient and wm group) are important, 
separate characteristics.  BTW, grouping never worked on 
Windows before - and I am now getting grouping with 
transients.  If we can move this behavior over to 'wm group', 
then I think we should be OK.

Logged In: YES 
user_id=72656

Is there a reference to this fact that transients should mirror 
the state of their master?  In the many years that I've 
programmed Tk, this has never been the expected behavior, 
and it is certain to break *a lot* of code (visually at least).

Logged In: YES 
user_id=68433

> The transient window is supposed to mirror state changes
in the master.

I think this new interpretation calls for a TIP.  In all
versions of Tk up to 8.4a4, and the ICCCM, [wm transient] is
nothing more than a hint to the window manager.

In particular, it has been possible (up until now) to
withdraw a transient independently of its master window and
have it stay withdrawn.  This change has already broken
parts of the core (not all of which have been fixed yet),
and is likely to break user code (mine, in particular).

Logged In: YES 
user_id=90858

I don't see this as a bug in the transient functionality.
The transient window is supposed to mirror state changes
in the master.

I guess we could add a flag so that one could explicitly
withdraw a transient window and keep it withdrawn even
when the master is mapped again.

Logged In: YES 
user_id=72656

Not only is this giving disastrous new behavior to 
comboboxes, but the changes have somehow affected the 
handling of other overrideredirect popups (like the BWidgets 
SelectColor::menu).  This is definitely something that needs 
to be addressed before 8.4b1.