tkwait visibility

: tkwait visibility name

Waits for a change in the visibility state (as indicated by the arrival of a <VisibilityNotify> event) of window name. This is typically used to wait for a newly-created window to appear on the screen before taking some action. Returns an empty string.

Note that this command is not particularly useful on non-[X11] platforms (Windows, OSX/Aqua) because <VisibilityNotify> events are never delivered. This is a platform limitation.

HaO 2015-12-03: I did not know that tkwait visibility does not work on windows.

HaO 2015-12-11: I face the issue, that tkwait never returns when the window is already visible. Is there a way to check this. Aim is just to assure that window is visible like:

if {![window already visible]} { tkwait visibility $w }

[winfo viewable $w]

perhaps?

2015-12-22 HaO: Good suggestion. It is perhaps like [winfo mapped]? When you show a window, but the background process to physically show it was not run, it already shows 1. Well, all this "background showing" is a myth to me...

Windows bug or whatever - looking for help

HaO 2015-12-02:

I had an issue today with tkwait visibility, I could not really track down.

A large application does the following:

# hide main window on initialisation
wm withdraw .
update
# initialisation of many things including main window
wm state . normal
catch {tkwait visibility .} ;# if error etc ommited for clarity
wm geometry . $SavedGeometry

Under strange totally unrelated circumstances (empty config file not present) but repeatable, the tkwait waits forever.

Thus, I have modified it as follows:

# hide main window on initialisation
wm deiconify .
update
# initialisation of many things including main window
wm state . normal
if {[winfo ismapped .]} {
    catch {tkwait visibility .} ;# if error etc ommited for clarity
}
wm geometry . $SavedGeometry

The "winfo ismapped" is only 0 if the tkwait will stall. I tried thousands of other things including update, wm deiconfy etc. With the upper patch, the window shows up quite delayed when tkwait is not used, but it shows up. The wm geometry is eventually not correctly honored (what the tk visibility is for) but that is better than nothing.

Anybody with the same experience may add to whether nail it down to a test script or whatever.

This is:

TCL 8.6.4 32 bit
Windows 10 64 bit (German)

HoMi 2015-12-16 (and changed on 2015-12-18):

The command "tkwait visibility" reacts on a "NotifyVisibility"-Event - this means a change of the visibility of a window, so it is correct that tkwait never returns when the window is already visible.

IMHO the command "tkwait visibility" is not required to show a window correct. The code above should be as follows:

# hide main window on initialisation
wm withdraw .
# initialisation of many things including main window
wm geometry . $SavedGeometry
update
wm deiconify .
wm raise .
focus -force .

Remarks:

The last two lines are required to bring the main window in front and give it the focus. As you can see, there is no "tkwait visibility ." in play.

HaO 2015-12-22: Thank you, [HoMi], for the contribution. This is all ok but does not get the point. The point here is that I see a bug with tkwait I wanted to transform into a ticket but I have not enough in my hands for that.

About your solution: The point is, that "wm geometry . $geom" is only honored when the window is really visible and when multiple "update" rounds have passed as there might be "Configure" events, which itself cause "Configure" events and all this must be passed. To get this moment, I used "tkwait visibility" which is very elegant in most cases.

See also edit