Ticket UUID: | 570764 | |||
Title: | Withdrawn transients resurrected | |||
Type: | Bug | Version: | obsolete: 8.4a5 | |
Submitter: | jenglish | Created on: | 2002-06-18 20:21:35 | |
Subsystem: | 65. Generic Window Operations | Assigned To: | mdejong | |
Priority: | 8 | Severity: | ||
Status: | Closed | Last Modified: | 2002-06-24 09:27:48 | |
Resolution: | Fixed | Closed By: | mdejong | |
Closed on: | 2002-06-24 02:27:48 | |||
Description: |
# 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. | |||
User Comments: |
mdejong added on 2002-06-24 09:27:48:
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. mdejong added on 2002-06-24 06:19:59: 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. mdejong added on 2002-06-22 08:44:18: Logged In: YES user_id=90858 Committed on 2002-06-21. hobbs added on 2002-06-22 08:28:11: Logged In: YES user_id=72656 fixes the problems on Windows. Please commit. jenglish added on 2002-06-22 08:19:19: 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. mdejong added on 2002-06-22 08:16:35: 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). hobbs added on 2002-06-22 07:58:02: 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. mdejong added on 2002-06-22 07:13:17: 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? hobbs added on 2002-06-19 08:15:11: 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 ... jenglish added on 2002-06-19 08:05:05: 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. mdejong added on 2002-06-19 07:37:51: Logged In: YES user_id=90858 I will work on a patch to add back the old behavior tonight. Stay tuned. hobbs added on 2002-06-19 07:10:16: 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. mdejong added on 2002-06-19 07:03:11: 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). hobbs added on 2002-06-19 07:03:10: 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. hobbs added on 2002-06-19 06:53:21: 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. mdejong added on 2002-06-19 06:39:55: 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. hobbs added on 2002-06-19 04:59:38: 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. hobbs added on 2002-06-19 04:57:26: 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). jenglish added on 2002-06-19 04:56:25: 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). mdejong added on 2002-06-19 04:19:11: 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. hobbs added on 2002-06-19 03:42:48: 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. |
Attachments:
- trans_withdraw.patch [download] added by mdejong on 2002-06-22 08:16:35. [details]