Tk Source Code

Attached is a patch to implement Tip #125 [wm manage]
and [wm forget] commands.  The patch includes Unix and
Windows implementations as well as a partial
implementation for MacOSX.  For Aqua, only the button
and menubutton widgets may be placed in a [wm manage]'d
frame.  To complete the implementation, the
TK_URBAN_RENEWAL flag must be recognized and handled by
all the intrinsic Tk widgets.  See the patch for details.

You'll note that this patch implments an alternative
approach to the original [wm topleve] proposal.  See
the updated Tip for details of this change.

Closing: <tt>wm manage</tt>/<tt>forget</tt> were implemented in Tk Aqua 8.5.15

Logged In: YES 
user_id=90580
Originator: NO

don't anticipate having time to do a full OSX implementation before 8.5.0, dropping prio

Logged In: YES 
user_id=72656
Originator: NO

Dropped in the HEAD.  Needs OS X implementation (code ifdef'd out).

File Added - 249838: tip125.diff

Logged In: YES 
user_id=72656
Originator: NO

Updated TIP #125 implementation - needs OS X finishing.
File Added: tip125.diff

Logged In: YES 
user_id=22949
Originator: YES

I've run some tests on Unix with the changes Joe suggested.  It seems to be fine.  I don't recall why the code was written that way.  The "Menu" test addresses the case of descendant toplevels as Menus have been the only descendant toplevel situation I've run into, probably by design.

I still need to see if similar code on Windows is necessary, no-ops, or incorrect.

-Brian

Logged In: YES 
user_id=68433

In unix/tkUnixWm.c, function RemapWindows: it's not
necessary to recursively call RemapWindows() for each child
window; you just need to call XReparentWindow() on the
outermost widget's Window.  IOW, the recursive calls to
RemapWindows(childPtr, winPtr) are either no-ops or (in the
case of descendant toplevels) incorrect.

Question: what is this for (also in RemapWindows())?

    if (strcmp(Tk_Class(winPtr), "Menu") == 0) {
      return;
    }


It's probably not necessary to call XGetWindowAttributes()
in this routine --
Tk already knows the X and Y coordinates (which are the only
fields of win_attr being used --
win_attr.x and win_attr.y are normally the same as
Tk_X(winPtr) and Tk_Y(winPtr), 
and besides they'll be overridden by the WM (in the case of
[wm manage]) or GM
(once remanaged after [wm forget]) anyway.

File Added - 201937: tip125_20061107.patch.gz

Logged In: YES 
user_id=22949

This updated patch is for the current HEAD (as of 11/7/06
approx 11:30pm pst)
This patch also fixes problems with focus.

File Added - 134612: tip125_files.tgz

Logged In: YES 
user_id=22949

I've added code to deal with focus management. I've also removed the 
restriction on frames and toplevels. In theory, any widget can be managed 
as a toplevel.  The class name is no longer changed, so a toplevel still has 
the class Toplevel when no longer managed by wm.

File Added - 95436: tip125_2.patch

Logged In: YES 
user_id=22949

I found a bug with the -menu option.  tip125_2.patch has the
bug fixed.

-Brian

File Added - 95342: tip125.patch