Subject: Re: FVWM: Reparent-bug in fvwm2

From: Bob Woodside <[email-masked]>
Date: Fri, 8 Nov 1996 21:23:51 -0500 (EST)

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.

	Seriously, I haven't seen any replies on the mailing list; have you
gotten any private e-mail responses about this problem?

	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?

	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.

	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.

	Cheers,
	Bob Woodside

--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Michael Schumacher <[email-masked]>
Date: Mon, 11 Nov 1996 13:40:08 +0100 (MET)

Hello everybody,

> 	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.
 
> 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).
 
> 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);

> 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.

> 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