Re: transient windows on win32

["Charles Reilly" <gtk-devel-list 2005 charlesreilly com>]

> gdk_window_win32_restore_transients ... I don't see any such function

Sorry, I reorganized the code and didn't update the comment.  The
ownership relation is restored by gdk_window_win32_owner_window_filter
calling gdk_window_win32_set_window_ownership.

> On X11 the color selector dialog also is only decorated with a "close"
> button, it can't be minimized or maximized. Any idea how to achieve
> this on Win32, too?

min/max buttons are more of a problem because, IIRC, they can't be removed
once a window has been created.

>> 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?

It needs to be slightly more complicated - if a window subsequently
becomes unowned then gdk should remember that
gdk_window_set_skip_taskbar_hint has been called and supply a temporary
owner.

>> 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?

I did try several designs.  I chose this one eventually because it changed
the existing behaviour as little as possible, so it was least likely to
break anything else.  But I agree that the existing behaviour is nasty, so
if you're happy to change it further, I am too.

>> 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?

My first attempt did exactly this.  There were two problems.

The first is cosmetic: it looks a bit scruffy if you have more than one
application window.  e.g. Suppose you have two inkscape drawings open with
a floating colour selector.  When you minimize the active window the
colour selector also disappears, then immediately reappears when the
second drawing gets focus and attaches to it.  If you have several
floating windows open there's quite a bit of flashing.  How does X handle
this?

The second problem was worse.  By rapidly minimizing and restoring two
drawings you could confuse the Windows window manager and end up with the
dialogs as the active windows, with no way of restoring the application
windows.  This can probably be fixed by being more careful about exactly
when ownership is transferred between application windows.  Basically, the
reason this is more complicated than just letting Windows do its thing is
because floating windows can be transferred between application windows in
gdk, but this isn't something that usually happens in win32 apps, and
Windows can become confused.

>> 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.

As above, this is slightly more complicated.

>> 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.)

This isn't a problem for inkscape.  gdk_window_set_transient_for is broken
on windows so inkscape doesn't call it; that's the extent of the
workaround.  Obviously I can't speak for other apps.

Anyway, thanks for the feedback.  I'll see if I can fix the second problem
I mentioned above in my original solution.  I've just started a new
contract so this may take a couple of weeks.

Cheers,
Charles