Hello everybody,
> On Tue, 5 Nov, 1996, Michael Schumacher wrote:
> > a Xterm...is reparented by a Tk frame widget and packed into another
> > toplevel. Unfortunately, the Xterm decorations won't disappear and fill
> > the whole background of the current screen.
>
> Hi, Mike --
>
> Well, that certainly is unattractive, isn't it? But it *is* big.
Yep, it's quite unattractive... ;) The reason why the (original) window is
very big (10000x10000) is that the Tk toplevel window can't tell the "stolen"
Xterm window to grow if it is resized by the user. Anyway, the Xterm window
should not be visible at all after being reparentized.
> Seriously, I haven't seen any replies on the mailing list; have you
> gotten any private e-mail responses about this problem?
No, but I contacted Charles Hines and he told me he would download tgdb and
see what's wrong with fvwm2 (no further replies since then, though).
> I spent a couple of late evenings trying to track the problem down,
> without much luck so far. I'm not familiar with what tksteal is doing
> internally - which extension does this belong to, and what version of Tk
> is your special wish based on? You'd think some other Tk apps would be
> stumbling across this, wouldn't you?
Well, it will affect all applications based on TkSteal (and generally every
application which tries to reparentize other windows in a similar way
as TkSteal), but it seems this extension is rarely used in Tcl-land, and
folks who use it probably still use fvwm1, mwm or any other window manager
which doesn't show this bug.
I'm happy to hear you could reproduce the bug even with the old version
of tgdb (so I'm sure now it has nothing to do with my local setup). The
new version is based on Tcl 7.6, Tk 4.2 (the old one was based on 7.3/3.6)
and TkSteal4.0 (all available from
ftp://ftp.neosoft.com/pub/tcl), but it
shows exactly the same behaviour regarding the debugee and shell windows.
What TkSteal basically does is:
- create a frame widget and another frame or label widget inside it
- as soon as the frame/label widget is mapped, the command "xaccess"
is called with the parameters:
"eventreparent -parentwidget frameOrlabel -windowid XidOfOtherWindow",
which executes the code below (excerpt from tkXAccess.c::969); "window"
contains the XidOfOtherWindow (i.e. the XID of the Xterm) mentioned above:
doreparent:
if (window != (Window) None) {
/* We found the window to reparent... now reparent it */
XSync(Tk_Display(tkrootwin), False);
XWithdrawWindow(Tk_Display(tkrootwin), window,
Tk_ScreenNumber(tkrootwin));
for (counter1 = 0; counter1 < REPARENT_LOOPS; counter1++) {
XReparentWindow(Tk_Display(tkrootwin), window, parent, 0, 0);
XSync(Tk_Display(tkrootwin), False);
}
XMapWindow(Tk_Display(tkrootwin), window);
if (!continueXAccess) {
XSync(Tk_Display(tkrootwin), False);
sprintf(error_buf, "event window reparent %ld to %ld", window, parent);
goto Xerror;
}
Tcl_ResetResult(interp);
sprintf(buf, "%ld", window);
Tcl_AppendResult(interp, buf, (char *) NULL);
}
XSync(Tk_Display(tkrootwin), False);
> I couldn't find any workarounds. Of course, since the orphaned frame
> still responds to window controls, you can get rid of it by closing it, but
> that's hardly what you want to tell users they have to do.
Closing the reparentized Xterm window (or iconifying it, for that matter)
will make it disappear, but it will also make it inaccessible from the
Tk toplevel window, so this is actually not a good idea.
> With a little hack tracing (looking specifically for a window carrying
> the title "Tgdb debugee"), I'm able to catch the UnmapNotify event that fvwm
> should be honoring (and isn't) , but I can't yet tell what distinguishes this
> particular window/event from a variety of others that fvwm wants to ignore, and
> I never see a ReparentNotify coming through. There are significant v1->v2
> changes in this area; I'm not familiar with their history, so puzzling
> this out is slow going. Can any fvwm old-timers out there shed any light on
> this area?
>
> If you've gotten any further info on this, or a fix, please let me
> know. Otherwise, I'll continue looking into it as time permits.
I'm also interested in being informed as soon as someone has a fix for
this behaviour. I'm not an X or fvwm expert, but please let me know if
you need more information I could provide, or if you have some code which
I could try out.
Thanks for your help,
mike
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Mon Nov 11 1996 - 06:40:32 GMT