wm transient
Mark G. Saye
I've put a few notes about transient windows on the wiki at
http://wiki.tcl.tk/3542
In summary, if you're writing code to create transient windows, you
should not forget to 'update idletasks' before the window is initially
mapped, or you may not get the full desired 'transient effect'.
Try:
toplevel .t
wm withdraw .t
update idletasks
wm transient .t .
wm deiconify .t
Mark /
--
Mark G. Saye
mark...@yahoo.com
Jeffrey Hobbs
>
> I've put a few notes about transient windows on the wiki at
> http://wiki.tcl.tk/3542
>
> In summary, if you're writing code to create transient windows, you
> should not forget to 'update idletasks' before the window is initially
> mapped, or you may not get the full desired 'transient effect'.
Can you elaborate on what platform and Tcl version you see this problem?
8.4 had quite a bit of changes related to transients done to it, and that
may have either fixed or broken what you expected. It would be good to
know which.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
Join us in Sept. for Tcl'2002: http://www.tcl.tk/community/tcl2002/
Mark G. Saye
>
> "Mark G. Saye" wrote:
> >
> > I've put a few notes about transient windows on the wiki at
> > http://wiki.tcl.tk/3542
> >
> > In summary, if you're writing code to create transient windows, you
> > should not forget to 'update idletasks' before the window is initially
> > mapped, or you may not get the full desired 'transient effect'.
>
> Can you elaborate on what platform and Tcl version you see this problem?
> 8.4 had quite a bit of changes related to transients done to it, and that
> may have either fixed or broken what you expected. It would be good to
> know which.
I'm using KDE 2.2.1 on Mandrake 8.1, and my posted observations were
based on tcl/tk 8.4b1.
Transient Properties (slightly different from wiki page):
1. .t ontop of .
2. minimize . -> minimize .t
3. geometry of .t unchanged when changing state of .
4. .t has no taskbar icon
5. .t has no minimize button
6. .t has no maximize button
Test code:
toplevel .t
wm withdraw .t
update idletasks
wm transient .t .
wm deiconify .t
With 8.4b1, I observe 1 2 3 4 5 6
With 8.3.4, I observe 1 2 3 4 5 6
However, if I remove the "update idletasks" in the code fragment:
With 8.4b1, I observe 2
With 8.3.4, I observe 1 2 3 6
Is there any other information that might be useful to you?
Thanks,
Mark G. Saye
>
> 8.4 had quite a bit of changes related to transients done to it, and that
> may have either fixed or broken what you expected.
Some more observations (and expectations) on transient windows (observed
on KDE 2.2.1 / Mandrake 8.1) :
I'll refer to a 'partially-transient window' as one which:
- will unmap (withdraw) when its parent is unmapped (iconified or
withdrawn)
- has all three window manager buttons (mimimize/maximize/close)
- most likely does not exhibit 'always-on-top' of parent behaviour
1. You can't iconify a transient window.
2. If a parent window is not mapped (i.e. iconified/withdrawn) when the
transient is created, what should happen?
A. the transient is created as partially-transient and mapped (8.4b1)
B. the transient is created as fully transient and mapped (8.3.4)
C. the transient is created and unmapped/withdrawn
-> I think C. is the right answer (but doesn't happen)
3. If the parent window is overrideredirect'ed when the transient is
created, what should happen?
A. the transient is created partially-transient with minimize and close
buttons (8.3.4 and 8.4b1)
B. the transient is created fully transient
-> I think B. is correct. If note 1. is correct (can't iconify
transients) then A must be wrong.
Here's a scenario:
Wish is running with multiple windows/applications. The root window (.)
is either withdrawn (what I usually do) or (following GPS's advice
http://wiki.tcl.tk/3175 ) it is overrideredirect'ed). I want to show a
warning/alert/alarm dialog, but which is not bound to an existing
application window. I'm thinking the window should be fully-transient
(i.e. only a close button. Hmmm, I rethinking my answer to note 2 above
- should the transient be withdrawn by default if the parent is
unmapped? Yes, I think maybe it should, but I should be able (in code,
not interactively) to deiconify and raise the transient independent of
its parent.
Maybe it would be more helpful for applications to have control over
what wm buttons are displayed? Just a thought ...
Ironically, all my expectations are met [*] using 8.3.4 on Windows 2000.
Comments?
Mark /
[*] ONLY regarding tcl/tk transient windows, not in general ;-}
Joe English
>Jeffrey Hobbs wrote:
>>
>> 8.4 had quite a bit of changes related to transients done to it, and that
>> may have either fixed or broken what you expected.
>
>Some more observations (and expectations) on transient windows (observed
>on KDE 2.2.1 / Mandrake 8.1) :
My advice: don't rely on any particular behaviour of
transient windows. There is absolutely no consistency
whatsoever across window managers.
Mo Dejong recently added some code to make Tk do the
"right thing" when running under WMs that do the
"wrong thing", which makes things more consistent,
but it's not 100% and never will be. ('"right thing"'
in quotes because nobody is really sure what the
Right Thing really is -- the ICCCM is maddeningly
vague on this and other topics.)
>I'll refer to a 'partially-transient window' as one which:
>- will unmap (withdraw) when its parent is unmapped (iconified or
>withdrawn)
>- has all three window manager buttons (mimimize/maximize/close)
[ Three? I see anywhere from one to six, depending on the theme,
not to mention depending on the WM. ]
>- most likely does not exhibit 'always-on-top' of parent behaviour
>
>1. You can't iconify a transient window.
>
>2. If a parent window is not mapped (i.e. iconified/withdrawn) when the
>transient is created, what should happen?
> A. the transient is created as partially-transient and mapped (8.4b1)
> B. the transient is created as fully transient and mapped (8.3.4)
> C. the transient is created and unmapped/withdrawn
> -> I think C. is the right answer (but doesn't happen)
D. Don't Do That:
"Clients should not rely on transient windows
being available to the user when the transient
owner window is not in the Normal state."
[ICCCM 4.1.4]
In this case, some WMs simply ignore the transient hint,
leading to case A.
Most WMs follow the policy that
"[...] WM_TRANSIENT_FOR windows should be iconified
when the window they are transient for is."
[ICCCM 4.1.10].
However, some enforce the policy that a transient's state
_always matches_ that of the master ("iconified" as an adjective),
leading to case C; while others iconify or withdraw transients
when their master _changes state_ ("iconified" as a verb),
leading to case B.
Still others ignore the policy altogether. (This is legal --
the elided part of the quotation above is "[Window managers
are free to decide if]").
> [...]
>Maybe it would be more helpful for applications to have control over
>what wm buttons are displayed? Just a thought ...
Yes, that would be nice, but there is simply no way to do it
under X11.
Now if you want something MWM/CDE-specific, it's possible.
If you want something KDE-specific [*]: well, you can't control
exactly what buttons are displayed, but you can select one of
several "window types", which will influence the display style.
If you want something specific to some other window manager,
that may or may not be possible, depending on the WM in question.
[ Actually, if you do want any of these things, post a followup
to Tk Feature Request #579885,
<URL: http://sourceforge.net/tracker/?func=detail&aid=579885&group_id=12997&atid=362997 >
This won't get implemented before Tk 8.5, maybe not even then,
but it never hurts to ask :-) ]
--Joe English
[*] I believe that GNOME-compliant WMs are supposed to follow the
same protocol as KDE3; I don't know if they do or not yet.
