#167 Tip #125 Implementation

[Brian Griffin]

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.

[Brian Griffin]

Patches on 8.5 HEAD for Tip #125

[Brian Griffin]

Logged In: YES
user_id=22949

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

-Brian

[Brian Griffin]

Patch on 8.5 HEAD for Tip #125 - bug fix

[Brian Griffin]

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.

[Brian Griffin]

modified files based on HEAD as of 5/15/05

[Brian Griffin]

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.

[Brian Griffin]

tip 125 patch based on HEAD as of 11/7/06

[Joe English]

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.

[Brian Griffin]

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

[Jeffrey Hobbs]

Logged In: YES
user_id=72656
Originator: NO

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

[Jeffrey Hobbs]

tip 125 from head of 2007-10-15

[Jeffrey Hobbs]

Logged In: YES
user_id=72656
Originator: NO

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

[Daniel A. Steffen]

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