What exactly is wm transient supposed to do, anyway?
R. T. Wurth
My colleagues seem to gravitate to me with stumper MRs, and they
really found a good one. It seems that a confirmation dialog box
("This is really dangerous: / Are you sure? / (button)YES :
(button)NO") was getting hidden when the folks from system test
clicked on the "main screen" of the application.
None of my developer colleagues could reproduce it. The dialog box
was a project-standard library we've been using, probably for 5+
years. So, I asked my colleague if he personally witnessed a tester
create the problem, and whether they could reproduce with other
dialog boxes and in other applications. He had witnessed it, and
they could reproduce it on other dialog boxes.
Normally, when something stops working, I ask "What changed?", but
in this case, I had to ask "What's different?" The only difference
is that management is too cheap to buy us developers Sun
workstations to mimic our users' environment, so we view our Tk GUIs
through an X-server running on PCs with MS-Windows, whereas system
testers do get real Suns. In both cases, the actual application
runs on an HP server.
Our Tcl/Tk environment is Tcl/Tk 8.4.1 (I know, we should upgrade,
but you try dealing with our configuration change process--we're
lucky to have gotten the upgrade from 8.2 pushed through.)
So, I examined the code and discovered that we are relying on [wm
transient] to keep the dialog box on top of the main application
screen. I looked up the man page, and my best interpretation of it
is something like: "we'll tell the window manager to make the first
window a transient child of the second window, and it might choose
to do something useful, or at least mildly interesting." :-) Am I
reading that description right? That the actual effect created by
[wm transient] is undefined, and very much window manager dependent?
Just what exactly is [wm transient] supposed to be doing?
Oh, about the application. We will probably use something like
the "modal dialog" binding method from Harrison & McLennan's
_Effective Tcl_ (<http://mini.net/tcl/159>). (See also the last few
dozen lines of:
<http://cvs.sourceforge.net/cgi-bin/viewcvs.
cgi/efftcl/efftcl/lib/scripts/dialog.tcl?rev=1.1.1.
1&content-type=text/vnd.viewcvs-markup>. Sorry about the wrapped
URL. I can't make my newsreader unwrap it.)
--
Rich Wurth / rwu...@att.net Rumson, NJ 07760 USA
Consultant to the telecom industry
Derk Gwen
# transient] to keep the dialog box on top of the main application
# screen. I looked up the man page, and my best interpretation of it
I gave up try to be clever. If I want to keep a window .dialog on top, I do
something like
proc acme w {raise $w; after 100 acme $w}
acme .dialog
--
Derk Gwen http://derkgwen.250free.com/html/index.html
Title does not dictate behaviour.
Joe English
>
>What exactly is wm transient supposed to do, anyway?
>
>is something like: "we'll tell the window manager to make the first
>window a transient child of the second window, and it might choose
>to do something useful, or at least mildly interesting." :-) Am I
>reading that description right? That the actual effect created by
>[wm transient] is undefined, and very much window manager dependent?
Yep, that's exactly right. Behaviour of transient windows
is completely unspecified.
>Just what exactly is [wm transient] supposed to be doing?
This is what the ICCCM has to say on the subject:
| The WM_TRANSIENT_FOR property (of type WINDOW) contains the ID
| of another top-level window. The implication is that this window
| is a pop-up on behalf of the named window, and window managers
| may decide not to decorate transient windows or may treat them
| differently in other ways. In particular, window managers should
| present newly mapped WM_TRANSIENT_FOR windows without requiring
| any user interaction, even if mapping top-level windows normally
| does require interaction. Dialogue boxes, for example, are an
| example of windows that should have WM_TRANSIENT_FOR set.
(See also <URL: http://tronche.com/gui/x/icccm/sec-4.html >
for other details. The above is the gist of it though.)
In practice, WMs typically keep transient windows
on top of their masters, iconify them when the master
is iconified, and omit the "Minimize" control. You
can't count on any of this though.
You might be tempted to force stay-on-top behaviour,
to accomodate WMs that don't do it themselves. There
are any number of recipes for doing this on the Wiki or
posted to this newsgroup. I *strongly* recommend that
you Don't Do That, though -- trying to second-guess the
WM nearly always leads to pain and anguish (especially
when you or a customer starts using a different WM).
If you find that an application seems to misbehave under
a particular WM, take consolation in the fact that many
other applications will seem to misbehave in the exact same
way, and the user is probably used to it. In fact, the
user might actually _want_ that behaviour, and chose that
particular WM for that very reason.
The ICCCM goes on to say:
| It is important not to confuse WM_TRANSIENT_FOR with
| override-redirect. WM_TRANSIENT_FOR should be used in those
| cases where the pointer is not grabbed while the window is
| mapped (in other words, if other windows are allowed to be
| active while the transient is up). If other windows must be
| prevented from processing input (for example, when implementing
| pop-up menus), use override-redirect and grab the pointer
| while the window is mapped.
In my experience, this is horrible advice: override-redirect
and keyboard grabs lead to even worse problems than inconsistent
transient behaviour.
--Joe English
Mark G. Saye
> What exactly is wm transient supposed to do, anyway?
>
> transient] to keep the dialog box on top of the main application
> screen. I looked up the man page, and my best interpretation of it
> is something like: "we'll tell the window manager to make the first
> window a transient child of the second window, and it might choose
> to do something useful, or at least mildly interesting." :-) Am I
> reading that description right? That the actual effect created by
> [wm transient] is undefined, and very much window manager dependent?
> Just what exactly is [wm transient] supposed to be doing?
It's possible that you are not getting the full transient effect. The
wiki page for "wm transient" may help you: http://wiki.tcl.tk/3542
If you can offer up code and environment that reproduces the problem, we
might be able to offer some more advice.
--
Mark G. Saye
markgsaye @ yahoo.com
Gerald Lester
> R. T. Wurth wrote:
>
>>What exactly is wm transient supposed to do, anyway?
>>...
> | It is important not to confuse WM_TRANSIENT_FOR with
> | override-redirect. WM_TRANSIENT_FOR should be used in those
> | cases where the pointer is not grabbed while the window is
> | mapped (in other words, if other windows are allowed to be
> | active while the transient is up). If other windows must be
> | prevented from processing input (for example, when implementing
> | pop-up menus), use override-redirect and grab the pointer
> | while the window is mapped.
>
> In my experience, this is horrible advice: override-redirect
> and keyboard grabs lead to even worse problems than inconsistent
> transient behaviour.
I'd like to second Joe's comment, unless you know *exactly* what you are doing
-- and if you have to ask the question you most likely don't -- stay away from
override-redirect and grab. You will give yourself a lot of pain if you do
not. Partciular stay away from global grabs.
That being said, both are useful -- but most often abused.
BTW, your WM may be configurable as to if transient windows stay on top or
not. You may want to check into the documentation.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester | "The man who fights for his ideals is |
| Gerald...@cox.net | the man who is alive." -- Cervantes |
+--------------------------------+---------------------------------------+
Eric Brunel
I do confirm that there are issues for transient windows on Solaris with CDE. In
fact, making a window transient with this environment seems to have almost no
effect: the decorations are the same and the transient window doesn't stay on
top of its master. The only effect seems to be that the transient window is
always iconified with its master.
I tested the recipe given on the wiki (sequence withdraw, update, transient,
deiconify), but the result is the same.
Tested with tcl/tk 8.3.4, Solaris 2.7 and CDE 1.3
--
- Eric Brunel <eric dot brunel at pragmadev dot com> -
PragmaDev : Real Time Software Development Tools - http://www.pragmadev.com
Markus Triska
> the "modal dialog" binding method from Harrison & McLennan's
> _Effective Tcl_ (<http://mini.net/tcl/159>). (See also the last few
> dozen lines of:
> <http://cvs.sourceforge.net/cgi-bin/viewcvs.
> cgi/efftcl/efftcl/lib/scripts/dialog.tcl?rev=1.1.1.
> 1&content-type=text/vnd.viewcvs-markup>. Sorry about the wrapped
> URL. I can't make my newsreader unwrap it.)
In the first version of two of my applications (available from
http://triskam.virtualave.net/tickletankle/tickletankle.html
and http://triskam.virtualave.net/alana/alana.html), I also used the
"modal dialog" from Harrison & McLennan, because I thought it was really
good.
However, this was not the case. A Tk-error occurred when you played
around with the application by repeatedly clicking on the main window
and the dialog box, and the box was not updated properly, either (go
check this!). Also, the code does not check if the window is already
created (that is, when the error occurs while the message box is still
being displayed).
So I crafted my own [transient_window] procedure which in my opinion
performs mutch better. It checks if the window is already being
displayed and centers it if this is the case. At least on KDE (which I
use), the "transient" property has the desired "modal" effect known from
Windows platforms, too, but I still strongly recommend to not depend
on this behaviour, and to make sure the application is not in an
unspecified state and reacts properly to input, even if the dialog box
is being displayed.
I'm using this improved procedure in many of my Tcl/Tk apps now. You can
have a look at the code on the links given above, and it is also used in
http://triskam.virtualave.net/finomaton/finomton.html.
Best regards,
Markus Triska.
Joe English
># So, I examined the code and discovered that we are relying on [wm
># transient] to keep the dialog box on top of the main application
># screen. I looked up the man page, and my best interpretation of it
>
>I gave up try to be clever. If I want to keep a window .dialog on top, I do
>something like
>
> proc acme w {raise $w; after 100 acme $w}
> acme .dialog
Beware that if you run this code under KDE with a version
of Tk prior to 8.4 -- the environment found, for example,
on Red Hat Linux -- the application is likely to lock up
and become completely unusable.
It's best to *really* give up trying to be clever, and just
use [wm transient]. If the WM doesn't keep transients on top,
that's because it doesn't *want* to keep transients on top.
Don't fight the window manager: it's likely to fight back.
--Joe English
NO on #157!
R. T. Wurth
> What exactly is wm transient supposed to do, anyway?
Many thanks to all who responded. I recommended to the project
that they accept the native (Solaris) behavior of transient
windows, when running under Solaris CDE, namely that if the
user manages to hide it with the main window, it is the user's
responsibility to unhide it. I did offer as an alternative the
application of the Harrison & McLennan modalDialog binding. It
is now up to the project's MR Review Board to decide.
In researching the problem I discovered that if I used a Sun
workstation running Solaris to directly log into an HP-UX
system, I got the HP-UX CDE behavior, namely that a transient
window is modal. So, it is a window manager issue, and it
looks like the "Common" Desktop Environment doesn't deliver
the cross-platform commonality its name claims it does.
--
Rich Wurth / rwu...@att.net / Rumson, NJ 07760 USA
Robert Heller
In a message on Sun, 28 Sep 2003 18:25:49 GMT, wrote :
RTW> In article <bko56q$334...@worldnet.att.net>, I wrote:
RTW> > What exactly is wm transient supposed to do, anyway?
RTW> > [...]
RTW>
RTW> Many thanks to all who responded. I recommended to the project
RTW> that they accept the native (Solaris) behavior of transient
RTW> windows, when running under Solaris CDE, namely that if the
RTW> user manages to hide it with the main window, it is the user's
RTW> responsibility to unhide it. I did offer as an alternative the
RTW> application of the Harrison & McLennan modalDialog binding. It
RTW> is now up to the project's MR Review Board to decide.
RTW>
RTW> In researching the problem I discovered that if I used a Sun
RTW> workstation running Solaris to directly log into an HP-UX
RTW> system, I got the HP-UX CDE behavior, namely that a transient
RTW> window is modal. So, it is a window manager issue, and it
RTW> looks like the "Common" Desktop Environment doesn't deliver
RTW> the cross-platform commonality its name claims it does.
It may in fact NOT be the CDE *code* but configuration settings off in
/etc/X11 or wherever Solaris and HP-UX store the various application
default files for the window manager(s).
RTW> --
RTW> Rich Wurth / rwu...@att.net / Rumson, NJ 07760 USA
RTW> Consultant to the telecom industry
RTW>
\/
Robert Heller ||InterNet: hel...@cs.umass.edu
http://vis-www.cs.umass.edu/~heller || hel...@deepsoft.com
http://www.deepsoft.com /\FidoNet: 1:321/153
Philipp Roessler
I'm wondering what happened to your window-or extension.
It worked quite well, didn't it!?
Phil