Tk Source Code

A toplevel window with overrideredirect set disappears completely.
Not known if its coordinates have been mangled or it is invisible or if
it is just not mapped.

Has this ever worked on mac os x?

toplevel .m
wm withdraw .m
wm overrideredirect .m yes
wm deiconify .m

wm withdraw .m
wm overrideredirect .m no
wm deiconify .m

Edit:

::tk::unsupported::MacWindowStyle style .m plain none

does not work either.  There is code (msgbox, bgerror) that uses 
::tk::unsupported::MacWindowStyle style .m movableModal/movableAlert.

Evidently everyone is OK with this now, so I am going to close this ticket and
merge the code.

@fvogel: Thanks!  The discussion in that ticket pretty much confirms my
suspicion.  The test was adjusted to match the behavior of certain window
managers.  But the behavior that the test was checking for is not required
by any language specification.

@Marc, I forgot to answer your question:

> the description of test wm-stackorder-5.2 says:
> 
> {A normal toplevel can't be raised above an overrideredirect toplevel}
> 
> Where does that come from?

Digging in the history, this was introduced by commit [9dab9a25b9], in resolution of [492259ffff] (I already mentioned this ticket in our discussion).

I discovered, thanks to the regression tests, that there was a bug in my implementation of negative coordinates for wm geometry. It showed up when changing the size but not the position. Check-in [328d9342] includes a fix for this. As long as I was digging around in the window manager code I decided I might as well fix the implementation of icon windows so that it would behave more or less correctly and stop causing tests to fail.

I also made some hopefully minor tweaks to the unixWM tests. On my Mojave system I am now seeing passes for all unixWM tests below 50.0.

Unfortunately this means that more testing is needed.

Results for me at [c3106c50] in the bugfix branch:

Mojave: the following previously failing tests now do PASS: unixWm-3.4, -3.5, -3.6, -3.7, -3.8, -3.9. No test is newly failing. The recently added "sleep 200" in unixWm-9.4 is of no help to make this test pass, it still fails.

Windows: test suite OK.

Linux: I didn't check.

Crashes are bad.
Please open a new ticket for those.
This ticket has a very specific focus, which has been addressed.

@marc_culler
as I'm facing a lot of crash like that:
https://pastebin.com/nG0Uub8v
https://pastebin.com/Gjq8Fvs4

I was wondering if it could be related.

By the way, another Apple preferences feature which interferes with the tests,
but is completely irrelevant in a real application, is the option to autohide
the dock. The tests assume that you *DO* autohide the dock.  If you run the
test suite without autohiding the dock and, say you have the dock on the left,
you will see some failures where a window was expected to have a location with
x < 44 but it shows up with x = 44 (assuming you have the dock size set to 44).
Sometimes the Apple window manager refuses to allow a window to overlap the
dock.  Some other times it doesn't care.  I have no idea how it decides, and
the tests should not need to account for how big the dock is.  So just hide
the dock when you run the tests.

@nab that stuff is absolutely not necessary in any normal Tk application.

Those tests that that have the delay were doing things likeiconifying a window,
then deiconifying it, then checking if thw window came back to the place
where it started.  Well, Apple has a very slow animation effect (the Genie
effect) that shows the window "swooping" into or out of the dock when it gets
iconified or deiconified. It is turned on by default.  The tests were failing
because they were checking the position of a window while it was in the middle
of its "swoop", so of course it had not gotten back to the starting position
yet.  The delay is there so the test will wait for the "swooping" to stop before
checking the window position.

I can't imagine a situation in a real app where you would care about this.  So
please ignore it.  It is *only* there to make a few tests pass.

Hi guys,
just for my information...
looking at your changes in unixWm.test, I wasn't aware that I should iconify the windows,  sleep, update, do stuff, deiconify, sleep again.
is that mandatory using aqua TK?
if so, in the .test you sleep for 200-250ms. can it be less?
isn't it the purpose of tkwait visibility? or can it be?

best regards,
++

Everything looks ready to go on my end.

Thanks, Kevin.  That works perfectly.

I pushed a small adjustment to the unixWm tests which makes a bunch more pass.
The tests were deiconifying a window and then checking its geometry.  But on
the mac the deiconification involves a very slow animation.  The tests need
to wait for that to finish before checking the geometry.

As far as I can tell, the bugfix branch is ready to be merged.  Please confirm!
If there are no further issues I will merge it on Monday.

I've pushed a fix to bug-185c8557d9 branch that addresses transient windows and "help"-styled windows (kHelpWindowClass set up using the MacWindowStyle command) in fullscreen state. These windows now behave as expected, i.e. staying in the same fullscreen space as the parent window.

I have revised the tests a little bit so that the specific behavior of each platform is tested.

@bll
ahora it is Week End...
I will try to provide some reproductible tests next week

++

@nab: I would open new tickets that address the specific issues with 
enter/leave and with mouse clicks passing through.  But test scripts
are needed to demonstrate the issues.

With the most recent check-in [7ea0be3c] to the bugfix branch, if you uncomment the second of these three lines:

	# To make things even worse on TkAqua, uncomment this line
	# wm overrideredirect .balloon 1
	wm withdraw .balloon 

then I think you will find that the help balloons work fine in FullScreen mode.

Do you have a test script that shows the issue with transient windows?

I agree that wm-stackorder-5.2 (and wm-stackorder-6.1) should be flagged as
inappropriate for Aqua.  As far as I can tell, the stacking restrictions
that they are checking for are:
* not required by the language specification
* not useful in the typical applications of overrideredirect windows
* not natural in the context of Apple's window manager (because *all* NSWindows
  appear in the stacking order and can be reordered)
* implementable at the script level if really needed.

I suspect that this is just a quirky behavior of some X11 window managers which
some people came to expect, but which is mostly irrelevant to applications.

I am going to commit this change to the bugfix branch, before I forget about it.
We can revisit it before merging, if something comes up.

The same fullscreen behavior is present in transient windows. 

What's necessary is to somehow keep these windows from going into fullscreen mode. Setting them as NSPanels (floating) might work, but the [tkLayoutChanged] call is not implemented there and that causes a crash.

In the sample script, to test the wm overrideredirect bits, comment out the MacWindowStyle flags.

package provide balloonHelp 0.1

## 
 # -------------------------------------------------------------------------
 # 
 # "Balloon Help" --
 # 
 #  Simple way of attaching balloon help to any tk window or class
 #  (anything we can use bind or bindtags on).
 #  
 #  The balloon is coloured appropriately, follows the mouse, appears
 #  and disappears and transitions reasonably, and tries hard to ensure
 #  it isn't placed half off the screen.
 #  
 #  It also handles appropriate transitions when moving from one
 #  help field to another, whether the underlying widgets/bindings are
 #  side by side, nested, or whatever.
 #  
 #  See 'help' comments below for usage.
 # -------------------------------------------------------------------------
 ##
namespace eval balloon {
    variable info
    # The delay until a balloon appears
    variable delay 650
    # The delay until a balloon is removed, once the pointer leaves
    # the area.
    variable delayTillRemoval 100
    # Use balloon help at all
    variable useBalloonHelp 1
    
    # If balloon help is set for windows which contain as children
    # other windows which also have balloon help, Tk doesn't give us
    # the kind of leave-enter events we want.  We keep a stack of
    # current nested balloon help requests to deal with this situation
    # properly.
    set info(stack) ""
    
    ## 
     # ---------------------------------------------------------------------
     # 
     # "help" --
     # 
     # Register some information with a particular tk window or tk class
     # (anything to which 'bind' and 'bindtags' may be applied).
     # 
     # For simplest possible balloon help, 'args' is just a single argument
     # containing the text to show when the user's mouse dwells on the item.
     # 
     # For most items, args will contain 2 arguments, in order:
     # 
     # 1) Text for item when enabled
     # 2) Text for item when disabled
     # 
     # However, for checkboxes, the above two pieces of text are used when
     # the item is 'off/unchecked', and an additional two arguments may
     # be given:
     # 
     # 3) Text for item when enabled and on
     # 4) Text for item when disabled and on.
     # 
     # If either of items 2/4 is empty, the default is to use items 1/3
     # respectively, and if item 3 is item, the default is to use item 1.
     # If the item finally chosen to be shown is empty, no balloon is shown.
     # ----------------------------------------------------------------------
     ##
    proc help {item args} {
	variable info
	
	if {![llength $args]} {
	    if {[info exists info($item,text)]} {
		return $info($item,text)
	    }
	    return
	}
	
	if {[winfo exists $item]} {
	    set hitem "Help-$item"
	    bindtags $item [concat [list $hitem] [bindtags $item]]
	    bind $item <Destroy> "balloon::end $item %W"
	} else {
	    set hitem $item
	}
	# Add bindings for the various events we need.
	# Make sure we don't add them twice in case they
	# are registered again.
	foreach {event script} [list \
	  <Any-Enter> "balloon::_start $item %W" \
	  <Motion> "balloon::_follow %W" \
	  <Any-Leave> "balloon::_hide \"$item\" %W" \
	  <Unmap> "balloon::_hide $item %W" \
	  <Button-1> "balloon::_button $item %W"] {
	    set old [bind $hitem $event]
	    if {[string first $script $old] == -1} {
		bind $hitem $event "${script}; [bind $item $event]"
	    }
	}
      
	set info($item,text) $args
    }

    proc forgetClass {item} {
	variable info
	foreach b {Any-Enter Any-Leave Button-1 Motion Unmap} {
	    regsub {^[^;]+ ; } [bind $item <$b>] {} old
	    bind $item <$b> $old
	}
	unset info($item,text)
    }
    
    proc forget {} {
	variable info
	if {[info exists info]} {
	    unset info
	}
    }
    
    proc end {item w} {
	variable info
	if {$item eq $w} {
	    if {[info exists info($item,text)]} {
		unset info($item,text)
	    }
	    _remove
	    
	    catch {
		bind $item <Any-Enter> ""
		bind $item <Any-Leave> ""
		bind $item <Unmap> ""
		bind $item <Button-1> ""
		bind $item <Destroy> ""
	    }
	} else {
	    _remove
	}
    }

    proc _button {item w} {
	variable info
	if {[info exists info($w,after)]} {
	    after cancel $info($w,after)
	    if {[winfo exists .balloon.l]} {
		_check $item $w
	    }
	}
	# On Aqua the balloons float above menus, so
	# we make sure we remove the balloons if we have
	# anything that looks like a menubutton.  We don't
	# use 'winfo class' because what we really care about
	# are the bindings.
	if {[tk windowingsystem] == "aqua"} {
	    if {[lsearch -exact [bindtags $w] "Menubutton"] != -1} {
		_remove
	    }
	}
    }
    
    proc _start {item w} {
	variable info 
	variable delay
	
	variable useBalloonHelp
	if {!$useBalloonHelp} { return }
	
	set top [lindex $info(stack) end]
	if {($top ne $w)} {
	    lappend info(stack) $w
	}
	
	if {[info exists info(after)]} {
	    # If a previous balloon is still showing, but we have
	    # already left it's window, and entered a new window, we
	    # should show the new balloon immediately.
	    
	    # Cancel destruction of previous balloon
	    after cancel $info(after)
	    unset info(after)
	    # Show new balloon
	    _show $item $w
	} elseif {[llength $info(stack)] > 1} {
	    # Show new balloon immediately
	    _show $item $w
	} else {
	    # No balloon is currently showing, so wait before presenting
	    # the user with their first balloon
	    set info($w,after) [after $delay "balloon::_show $item $w"]
	}
    }

    proc _remove {} {
	# This procedure may be called twice if we 'end' balloons,
	# while an 'after' call is still outstanding.  So we just
	# need to make sure that it doesn't mind a second call.
	::destroy .balloon
	variable info
	if {[info exists info(after)]} {
	    after cancel $info(after)
	    unset info(after)
	}
    }
    
    proc _follow {w} {
	if {[winfo exists .balloon]} {
	    set y [winfo pointery $w]
	    if {[tk windowingsystem] eq "aqua"} {
		if {$y < 33} {
		    _remove
		    return
		}
	    }
	    _checkPosition [expr {[winfo pointerx $w] + 20}] \
	      [expr {$y + 20}]
	}
    }
    
    proc _checkPosition {posx posy} {
	if {[winfo exists .balloon]} {
	    set width [winfo reqwidth .balloon]
	    set height [winfo reqheight .balloon]
	    
	    #puts "$posx $posy $width $height"
	    # If right side is offscreen, move to the left...
	    if {$posx + $width > [winfo screenwidth .balloon]} {
		set posx [expr {$posx - 40 - $width}]
	    }
	    # ... but not too far.
	    if {$posx < 0} { set posx 0 }
	    
	    # If bottom is offscreen, move up...
	    if {$posy + $height > [winfo screenheight .balloon]} {
		set posy [expr {$posy - 40 - $height}]
	    }
	    # ... but not too far.
	    if {$posy < 0} { set posy 0 }
	    wm geometry .balloon "+${posx}+${posy}"
	    update idletasks
	}
    }
    
    proc _show {item w} {
	#puts "show $item $w"
	if {![winfo exists $w]} {
	    _hide $item $w
	    end $item $w
	    return
	}
	
	variable info
	variable delay
	
	set top [lindex $info(stack) end]
	if {($top ne $w)} {
	    # If we're not top of the stack, reschedule
	    set info($w,after) [after $delay "balloon::_show $item $w"]
	    return
	}
	
	# the position of the balloon window
	set posx [expr {[winfo pointerx $w] + 20}]
	set posy [expr {[winfo pointery $w] + 20}]

	# The .balloon often exists from the previous balloon
	::destroy .balloon
	switch -- [tk windowingsystem] {
	    "classic" {
		toplevel .balloon -relief ridge -borderwidth 2 \
		  -class Balloonhelp ; ::tk::unsupported::MacWindowStyle\
		  style .balloon floating none
	    }
	    "aqua" {
		toplevel .balloon -relief flat -borderwidth 2 \
		  -class Balloonhelp ; ::tk::unsupported::MacWindowStyle\
		  style .balloon help none
	    }
	    "win32" {
		toplevel .balloon -relief ridge -borderwidth 1 \
		  -class Balloonhelp 
	    }
	    default {
		toplevel .balloon -relief ridge -borderwidth 2 \
		  -class Balloonhelp 
	    }
	}
	.balloon configure -background yellow
	
	if {[tk windowingsystem] == "classic"} {
	    ::tk::unsupported::MacWindowStyle style .balloon\
	      floating none
	} elseif {[tk windowingsystem] == "aqua"} {
	    ::tk::unsupported::MacWindowStyle style .balloon\
	      help none
	    # Workaround TkAqua bug.
	    bindtags .balloon [concat AlphaToplevel Alpha [bindtags .balloon]]
	} else {
	    wm overrideredirect .balloon 1
	}
	# To make things even worse on TkAqua, uncomment this line
	#wm overrideredirect .balloon 1
	wm withdraw .balloon 
	#wm geometry .balloon "+${posx}+${posy}"

	set text [_text $item $w]
	if {[string length $text] > 500} {
	    set wraplength 3i
	} else {
	    set wraplength 2i
	}
	
	::label .balloon.l -text $text \
	  -bg yellow -foreground black \
	  -bd 0 \
	  -justify left -wraplength $wraplength -padx 6 -relief solid \
	  -highlightthickness 0
	
	pack .balloon.l

	# make it visible
	if {$text != ""} {
	    update idletasks
	    _checkPosition $posx $posy
	    # Unfortunately the above line can also destroy the balloon!
	    if {[winfo exists .balloon]} {
		wm deiconify .balloon
		raise .balloon
	    }
	}
	set info($w,after) [after $delay "balloon::_check $item $w"]
    }
    
    proc _text {item w} {
	variable info
	# In principle we allow four different pieces of text to be
	# associated with each item.  In practice we only use 1 or 2.
	# This flexibility is nicely compatible with MacOS balloons.
	
	set offset 0
	if {![catch {$w cget -state} state]} {
	    if {$state == "disabled"} {
		incr offset 1
	    }
	}
	
	switch -- [winfo class $w] {
	    "Checkbutton" {
		# Checkbuttons display a different help text if the
		# box is checked or not.
		set value [uplevel \#0 set [$w cget -variable]]
		if {$value == [$w cget -onvalue]} {
		    incr offset 2
		}
	    }
	}
	
	set text [lindex $info($item,text) $offset]
	if {$text == "" && ($offset & 1)} {
	    incr offset -1
	    set text [lindex $info($item,text) $offset]
	    if {$text == "" && ($offset & 2)} {
		incr offset -2
	    }
	    set text [lindex $info($item,text) $offset]
	}
	append text "\nfocus is [focus]"
	return $text
    }
    
    proc _check {item w} {
	variable info
	variable delay
	if {![winfo exists $w]} {
	    catch {_hide $item $w}
	    end $item $w
	} else {
	    if {[winfo exists .balloon.l]} {
		set top [lindex $info(stack) end]
		if {$top eq $w} {
		    set text [_text $item $w]
		    if {$text == ""} {
			wm withdraw .balloon
		    } else {
			.balloon.l configure -text $text
			wm deiconify .balloon
		    }
		}
		set info($w,after) [after $delay "balloon::_check $item $w"]
	    }
	}
    }
    
    proc _hide {item w} {
	#puts "hide $item $w"
	variable info 
	variable delayTillRemoval
	if {[info exists info($w,after)]} {
	    after cancel $info($w,after)
	    unset info($w,after)
	}
	set top [lindex $info(stack) end]
	if {$top eq $w} {
	    set info(stack) [lreplace $info(stack) end end]
	}
	if {![llength $info(stack)]} {
	    set info(after) [after $delayTillRemoval "balloon::_remove"]
	} else {
	    # workaround for bug on macosx
	    while {[llength $info(stack)] \
	      && ![winfo exists [lindex $info(stack) end]]} {
		set info(stack) [lreplace $info(stack) end end]
	    }
	    if {![llength $info(stack)]} {
		set info(after) [after $delayTillRemoval "balloon::_remove"]
	    }
	}
    }
    
}

if {0} {return}

toplevel .tt
pack [text .tt.t] -fill both -expand 1
for {set i 0} {$i < 20} {incr i} {
    .tt.t insert end "\nhere is some text on line $i"
}
balloon::help .tt.t "here's some help"

Marc, I've noted another bug here. When a window is in fullscreen mode, calling an overrideredirect window causes that window to hijack its own fullscreen space. In practical terms, this means a tooltip/balloon help window over an icon will suddenly jump into a separate fullscreen space by itself. The attached script illustrates the problem; just run it in regular screen, then switch to fullscreen and watch the tooltip take over the screen and make it yellow. I've tried playing with the window flags a bit and the collection behavior, but nothing has worked for me. Perhaps you'll have better luck.

@fvogel: I don't think a special case should be added to the code to 
add a restriction that's not needed.  Better to just add !macos to the
two tests.  (And that would be difficult, messy code).  If X11 and/or
windows have specific stacking orders for overrideredirect windows, 
that's their restriction.  Don't force it on macos.

@nab: Not never.  But when it does it is not entirely clear to me.
If I click in the window, I get the messages.  I use focus follows
mouse, maybe a different focus model works better???.  
I do not think this is a new issue, I have a vague recollection
of having trouble with toplevels and enter/leave.

another issue with wm overrideredirect .m yes
I cannot bind .m <Leave>
.m is never notified that mouse pointer leave the window.

is it the same for you?
++

I could not find anything in the Tk documentation which says that a normal
toplevel is not allowed to be raised above a toplevel with the overrideredirect
flag set.  But the description of test wm-stackorder-5.2 says:

{A normal toplevel can't be raised above an overrideredirect toplevel}

Where does that come from?

I don't know the exact rules regarding restrictions on raising/lowering toplevels and overrideredirected toplevels. I stumbled on the topic when I investigated the failing stackorder-5.2 (see ticket [4305d9fa23]). I only know what's written in this ticket and what I found by making archaeological researches that popped [492259ffff] out from those researches. I didn't dig further at this time but it seems that the ICCCM is silent on the topic, or not precise enough (I don't remember what's in the relevant section), so that window managers may or may not maintain managed and unmanaged windows in the same stack, possibly creating constraints on raising/lowering windows depending on the fact one is managed and the other one is an overrideredirected one.

Basically it seems that the tests (stackorder-5.2 and -5.3) would give the rules?

Final note: Your latest commint [76712c70] in the bugfix branch now makes the following previously failing tests PASS on Mojave: unixWm-2.4, -2.5, -2.6, -2.7, -2.8, -2.9, -44.7, -44.8

When I run the commands from stackorder 5-2 and 5-3 in Wish what I see is that
there are no restrictions on raising or lowering either an ordinary toplevel
or an overrideredirect toplevel.  Either one can be raised above or lowered
below the other one.  I did not know about any such restriction, so I didn't
write any code to create one.  And I don't see any checks of the
overrideredirect flag in the implementations of either XRaiseWindow or XLowerWindow.

So I think the results of these two tests are random, possibly influenced by
previous tests or just affected by timing.

What are the rules, exactly?

[19d661bf] made the following tests results change from FAIL to PASS: unixWm-23.2 and wm-iconify-2.1 (these two thanks to the re-inserted dash in "override-redirect" error message), unixWm-51.8, and stackorder-5.2

This commit however started to make text-14.19 and text-14.20 newly fail. However this got fixed just in the next commit: [76f6536b], that fixed a lot of unixWm tests.

That's great, thanks Marc!

The only newly failing test in the bugfix branch now is stackorder-5.3. This happened first at [19d661bf].

==== wm-stackorder-5.3 An overrideredirect window can be explicitly lowered FAILED
==== Contents of test case:

    toplevel .t
    wm overrideredirect .t 1
    lower .t
    update
    raiseDelay
    wm stackorder .t isbelow .

---- Result was:
0
---- Result should have been (exact matching):
1
==== wm-stackorder-5.3 FAILED

The failure status is now reverted between stackorder-5.2 and -5.3. This rings a bell for me, please have a look at [4305d9fa23]:

- I had found the origin of the difference between stackorder-5.2 and -5.3 in that ticket.

- [4305d9fa23] perhaps may be closed now.

well... update was fast...

as bll said, this works
toplevel .m
wm withdraw .m
wm overrideredirect .m yes
wm deiconify .m


this lead to under window to receive input
toplevel .m
tkwait visibility .m
wm overrideredirect .m yes

++

I'm updating to 10.14.2
will retry tomorrow with/out  tkwait visibility

++

Tested the latest changes.
Looks good.  The following worked fine.

toplevel .m
wm withdraw .m
wm overrideredirect .m yes

ttk::entry .m.e 
pack .m.e -in .m

set ::v 0
after 5000 [list set ::v 1]
vwait ::v

wm deiconify .m

Can't reproduce nab's issue.

That's probably the usual problem with clicks passing through (e.g.
press is captured and release passes through), and not a specific
issue with overrideredirect.

I've tried 19d661bf  with:
toplevel $masterWin
tkwait visibility $masterWin
wm overrideredirect $masterWin 1

when the borderless toplevel is not entirely above the main window of my app, if I click on an item of $masterWin, the clic go through the window...
Finder window was under and the clic went to Finder.

hope this help.
++

IMO removal of the dash in the error message made in [5ce80a0a2e] should either be reverted or propagated to the other platforms, to tests expected results, and to the man pages. The current situation is not homogeneous and would require tests results specialization for no reason I can see.

(forgot to mention: that was on Mojave)

Lunching the tests in the bugfix branch I see improvements:

Do no longer fail:

==== unixWm-7.1 override_redirect and Tk_MoveTopLevelWindow FAILED
==== Contents of test case:

    list [winfo ismapped .m] [wm state .m] [winfo x .m] [winfo y .m]

---- Result was:
1 zoomed 100 200
---- Result should have been (exact matching):
1 normal 100 200
==== unixWm-7.1 FAILED

==== unixWm-7.2 override_redirect and Tk_MoveTopLevelWindow FAILED
==== Contents of test case:

    list [winfo ismapped .m] [wm state .m] [winfo x .m] [winfo y .m]

---- Result was:
1 zoomed 150 210
---- Result should have been (exact matching):
1 normal 150 210
==== unixWm-7.2 FAILED


==== unixWm-38.3 Tk_WmCmd procedure, "withdraw" option FAILED
==== Contents of test case:

    set result {}
    wm withdraw .t
    lappend result [wm state .t] [winfo ismapped .t]
    wm deiconify .t
    lappend result [wm state .t] [winfo ismapped .t]

---- Result was:
withdrawn 0 zoomed 1
---- Result should have been (exact matching):
withdrawn 0 normal 1
==== unixWm-38.3 FAILED

Newly fail (straightforward to fix, the error message was apparently changed and the test was not updated):

==== unixWm-23.2 Tk_WmCmd procedure, "iconify" option FAILED
==== Contents of test case:

    destroy .t2
    toplevel .t2
    wm overrideredirect .t2 1
    set result [list [catch {wm iconify .t2} msg] $msg]
    destroy .t2
    set result

---- Result was:
1 {can't iconify ".t2": overrideredirect flag is set}
---- Result should have been (exact matching):
1 {can't iconify ".t2": override-redirect flag is set}
==== unixWm-23.2 FAILED

==== wm-iconify-2.1 Misc errors FAILED
==== Contents of test case:

    toplevel .t2
    wm overrideredirect .t2 1
    wm iconify .t2

---- Result was:
can't iconify ".t2": overrideredirect flag is set
---- Result should have been (exact matching):
can't iconify ".t2": override-redirect flag is set
==== wm-iconify-2.1 FAILED

# no window at all
toplevel .m
wm overrideredirect .m yes

So I had the wait and the withdraw/deiconify.

Your method works.  Which is fine for many needs (e.g. tooltips).
This 'tkwait visibility' can be documented for mac.  Certainly much 
easier to understand than figuring out withdraw/deiconify/raise/update
combinations that work.

"supposed to be possible"?  I don't know.  On Linux and Windows, yes, you can.
So much of this area is highly dependent on the underlying system, it's hard 
to make it work the same.

For the particular application I was working on (menus), this will not 
work unless I recode to delay instantiating the window until the first 
time it is drawn.  Which I'm not going to worry about until this 
bugfix hits production.  My menus can also use frames as an alternative.

@bll this script opens a borderless toplevel for me when I run it with tclsh:

package require Tk
toplevel .m
tkwait visibility .m
wm overrideredirect .m yes

Does that work for you?

Is it supposed to be possible to set overrideredirect before a window is mapped?

Your script also works for me, but it waits a second before opening the
borderless window. I don't really understand the purpose of all of the raising
and waiting and withdrawing and deiconifying, but it doesn't seem to break
anything.

Also, I don't see any timing weirdness.  Can you please explain what is weird?

I will add that the bug fix branch seems to cause no harm so I have no objection to its inclusion.

The primary reason for the overrideredirect command (to draw a borderless window without any decoration from the window manager such as close button or title) is tooltips or balloon help; it may also be used as a splash screen. As before, I don't think any re-work at the C level is needed to get that working--script level code is the appropriate change. Testing both the bug fix branch and core-8-6-branch, I don't see a substantial change in the borderless windows.

Finally got a build to work with tcl/core-8-6-branch and the tk bug branch

This works to get a window.  I don't know how much of a delay is necessary.
But the window looks correct now (I'm running with a script, not interactive
this time).  Oh, I see, it works great in interactive mode now, not so
much scripted.  Lots of timing weirdness.

toplevel .m
wm overrideredirect .m yes
raise .m

set ::v 0
after 1000 [list set ::v 1]
vwait ::v

wm withdraw .m
wm deiconify .m

The bug-185c8557d9 branch now also includes a fix to a vaguely related bug that withdrawn windows would get redisplayed as unusable windows if the Wish application icon were clicked while Wish was running. This is in check-in [9d66b57b].

I think this is fixed in the bug-185c8557d9 branch. It took a few adjustments here and there, but nothing major. It makes sure that setting or clearing overridedirect makes the window move out of or into the Window menu. Apart from that I believe that this only changes the appearance of overrideredirect windows and does not change any behaviors, but this needs to be checked since I don't understand the intended behavior very well.

This also fixes a bug where withdrawn windows would have zoomed state when they get deiconified. I thought it might be related, but I don't think so any more.

One thing to point out: it does not seem to matter whether the window is withdrawn when the state of the overrideredirect flag is changed. At least the title bar disappears when the flag is set and reappears when the flag is cleared regardless of whether the window is withdrawn. Possibly there are other differences which I did not notice.

The code is in check-in [5ce80a0a].

That type of bug might explain why I get no window at all.

I have a withdraw/overrideredirect.

Then much later in time, I have the deiconify/raise.

I'm afraid there is some sort of subtle bug here.  I ran the following
commands in Wish, using the current tip of core-8-6-branch:

toplevel .m
wm withdraw .m
wm overrideredirect .m yes
wm deiconify .m
raise .m

If I paste all of those commands into Wish at once I get a window with no
title bar which cannot be moved.

But if I type those commands one at a time then I get a window
which has a title bar.  The stoplight buttons are grayed out and
do not respond to the mouse, but the window can be moved.

That's fine.
If it can't work, it can't work.

When it does work, I saw in one test it is not working the same as on 
other systems, decorations grayed out, title bar still present.
So not really useful.

I am simply not aware of any way to implement this except as currently coded. 

I've submitted and fixed several bugs to other projects--Python/IDLE, TkDiff--by suggesting some combination of raise and update idletasks to get balloon help, call tips, and similar functions working using the overrideredirect API. These calls are simply necessary at the script level, and if you're not seeing it, it may be necessary to play around a bit more.

I am aware of the focus/raise/update, but nevertheless, the 
window does not get drawn.   Sometimes if I cause it to close,
open, close, open, it may eventually get drawn.

Whether the implementation is correct or not, the window
should get drawn after a 'wm deiconify' and the event loop
is re-entered.

If it needs to be raised, no big deal, but there is no 
window on the screen that is displayed.

Hi,
ballon help does not work at all on macOS 10.14...

++
Nicolas

After trying a few different approaches, I reviewed the history of the overrideredirect implementation on macOS and have concluded it's correct; see ticket 1472624 for the background. Essentially, older implementations grabbed focus from the main window, which is the wrong behavior. Because the window is not automatically activated, its display will need to be accompanied by "raise" and "update idletasks." If you look at most implmementations of tooltips or balloon help at the wiki, they have some combination of these calls.  So I plan to close this as invalid.

Regarding overrideredirect, I've observed this behavior; working on a fix. Regarding the MacWindowStyle command, you may have to play with the flags to get something working - some of it doesn't work anymore and is poorly documented by Apple.