: '''wm transient''' ''window ?master?'' If ''master'' is specified, then the window manager is informed that ''window'' is a transient window (e.g. pull-down menu) working on behalf of ''master'' (where ''master'' is the path name for a top-level window). If ''master'' is specified as an empty string then ''window'' is marked as not being a transient window any more. Otherwise the command returns the path name of ''window'''s current master, or an empty string if ''window'' isn't currently a transient window. A transient window will mirror state changes in the master and inherit the state of the master when initially mapped. It is an error to attempt to make a window a transient of itself. <> ''[MGS]'' - If you are creating a transient window, the full 'transient effect' may not kick in properly until the window has been in a fully unmapped state. It's possible that you may not even notice that it's not fully transient. Just setting the transient flag before the window is initially mapped may not have the full desired result. From my understanding: 1. The transient window should always remain on-top, or in front, of the master window. 2. Minimizing the master window should also minimize/withdraw the transient window. 3. The geometry of the transient window should not change when moving/resizing/minimizing/maximizing the master window. 4. The transient window should never have an application (taskbar) icon. 5. The [window manager] should not draw minimize buttons for the transient window (only a close button and possibly a maximizebutton). I do NOT think the maximize button will be hidden and a quick test with xfwm4 confirmed that. 6. Transient windows may or may not be resizable. The [window manager] should provide hooks to resize the window. Some of these (probably just 5) may be dependent on the window manager. If your window is not fully transient (as mentioned above) 1, 3 and/or 5 may not happen. ---- [jenglish] As a matter of fact '''all''' of them are WM-dependent. Most window managers I've seen do #1 and #4, and use a smaller set of window decorations (usually just a close button and sometimes a menu button). #2 is also pretty common. The transient flag is only a hint; you shouldn't depend on any particular behaviour. ---- Of course, I've probably got this all wrong, and I should read the [ICCCM]. If you're writing code to create a transient window, you should either: * wait until your toplevel is mapped, then make it transient, then withdraw and deiconify, OR * create your toplevel, withdraw it, update idletasks, mark as transient, and then deiconify. I favour the second approach, as follows: toplevel .t wm withdraw .t update idletasks wm transient .t . wm deiconify .t ---- [jenglish] Window managers are only required to examine the transient field when the window transitions from the Withdrawn to the Normal state, so the above is correct. You can also just do: toplevel .t ; wm transient .t . since .t won't be mapped until the next ''update'', ''update idletasks'', or the event loop is reentered. ''[MGS]'' - Unfortunately, this 1-2 liner doesn't work for me (Linux, kwin/KDE 3). I have to resort to the 5 lines above. ''[MGS]'' - As I understand it, a newly created window is not in a Withdrawn state, so it can't transition from Withdrawn to Normal, and so the wm doesn't (properly) examine the transient field. Or this yet again quite wm-specific? ---- ''[MGS]'' [[2003/04/18]] - It appears that the transient master must be mapped (not withdrawn or iconified) at the time of the '''wm transient''' command, for the full transient effect to be in operation. wm withdraw . update idletasks toplevel .t wm withdraw .t update idletasks wm transient .t . ; # This line doesn't give full transient effect, because . is not mapped wm deiconify . update idletasks wm transient .t . ; # If you remove this line, you won't get full effect wm deiconify .t ---- [SSch] Notice, that ''wm transient'' transient does not work correctly, if it used in combination with [wm overrideredirect]. On Win2K I got just the opposite effect: The overrideredirect'ed ''window'' was always below the ''master''... ---- ''[Glenn Halstead]'' [[2003/04/19]] I often use '''[grab]''' along with '''wm transient''' to create modal operation - i.e. the user may not select the parent window unitl he has closed the child window. ----- [MK] I am creating a toplevel window. I want that i can iconify the window and also make it transient. Is there any way to make a transient toplevel and user can also iconify and deiconify it??? [MG] On MS Windows, at least, it seems you can't iconify a transient window - trying to do so directly with something like toplevel .f wm transient .f . wm iconify .f raises an error. Transients are minimized (iconified) when the window they're linked with is, though. If you want to remove the transient, you can do it with wm withdraw $transient though, and bring it back with wm deiconify $transient ---- ---- ''[DCG]'' Update idletasks is not really needed. You can do it like this: wm overrideredirect $toplevel2 1 after idle "set finished 1" vwait finished wm transient $toplevel2 $toplevel1 [Lars H]: Is there any reason that would be better, though? A disadvantage is that it creates a dependence on an ad-hoc global variable ''finished'', and it's longer. What's the plus side of it? That it doesn't necessarily process all idle tasks (but only those up to the '''after idle''')? ''[DCG]'' With this, you are waiting until the windows manager is finished, not forcing it to finish all the queued tasks, letting the wm manager to handle this. Also, to force the the update, as far as I know is a costful operation. Anyway, I don't say that is better, it's only different. <> ---- **See also** * [wm] * [Window manager] * [grab] * [dialog] ---- !!!!!! %| [Category Command], a part of [Tk] | [Tk syntax help] | [Category Introspection] |% !!!!!!