Re: transient windows on win32

[Tor Lillqvist <tml iki fi>]

Now finally answering the actual message from Sep 4th...

Charles Reilly writes:
 > The trivial problem was that gdk_window_set_skip_taskbar_hint set the
 > window owner.  This overwrote the window owner set by
 > gdk_window_set_transient_for.  (I guess this was deliberate, since
 > transients didn't work anyway?)

I don't think it was deliberate, but just an oversight. Probably
gdk_window_set_skip_taskbar_hint(TRUE) should just have let the owner
be for already-owned windows, as they already aren't visible in the
taskbar, no?

 > The non-trivial problem was caused by the windows taskbar.  Normally, when
 > you minimize a window, Windows automatically hides any owned (transient)
 > windows.  GDK suppresses this, so owned windows stay visible.

Actually, I think that was probably a bug. Isn't one of the main
points of calling gdk_window_set_transient_for() to make the transient
window hide itself automatically if the owner window is minimized or
hidden, and to make it not have minimize or maximize buttons?

 > The solution I've implemented is to disconnect the owned window
 > from its owner when the owner window is minimized, and to restore
 > the ownership relation when the owner is restored.

I think your solution might be wrong and too complex. I now think what
should be done is to just let Windows do its thing, hide any owned
(transient) windows when the owner is minimized, and show them when
the owner is restored. Or is there some gotcha I didn't consider?

 > If set_skip_taskbar_hint has been called the owned window is given
 > a temporary owner (rather than no owner) to keep it off the taskbar
 > while the owner is minimized.

Setting skip_taskbar on a window that already is transient_for
probably should be a no-op on Windows? Setting skip_taskbar for a
non-owned window could use the temporary owner window stuff.

 > If you want to try this with inkscape you need to edit the inkscape
 > functions sp_transientize and sp_transientize_callback in
 > dialog-events.cpp to comment out the "#ifndef WIN32"/"#endif" lines.

Hmm, if apps like Inkscape already contain workarounds for real (or
perceived) bugs in gdk/win32 window state management, will such apps
then get completely confused if these gdk/win32 bugs are fixed?
("fixed" in the sense that apps without such workarounds like gtk-demo
start behaving more like with typical X11 window managers.)

--tml