Re: [gtk-win32] Bugfix for transient dialogs posted a year ago



Engelen, J.B.C. (Johan) writes:
 > Did this get committed eventually? 

No, sorry. There is a whole complex of more or less tightly
interrelated issues related to window relationships in gdk/win32. See
the mail messages attached to
http://bugzilla.gnome.org/show_bug.cgi?id=112404 See also the other
bugs referenced to by comments in that bug.

The Reilly patch looked fine initially, but then when I actually used
it a bit more, it turns out that for instance Gaim starts behaving
badly when run against a GTK+ with the patch: Occasionally the main
Gaim window (the one with the IRC (etc) dialogues in tabs) gets the
WS_EX_TOPMOST extended style bit set, which is very irritating. The
exact mechanism that causes this is unknown. It doesn't happen
repeatably all the time, just sometimes, and might then as
mysteriously gets turned off again later...

It seems that it is also hard to find a definitive X11 reference
window manager to verify what the correct behaviour of test programs
should be. Personally I use SLED10, with GNOME and metacity, and in
that combination a test program by Bulia Byak (attached to the bug
mentioned above) behaves in a quite silly way, while he says that in
KDE it behaves differently, in the way he expects it to. Is metacity
badly broken and KDE more correct? And how can we be sure that the
behaviour on KDE that Bulia sees is the correct and intended one, and
not just a coincidence? (Anyway, I wouldn't want to set up yet another
Linux (virtual) machine with a KDE environment just to use as a
reference platform.)

I guess an otherwise trivial and GNOME/KDE-agnostic window manager
with no eye-candy and few if any user-tunable options that would
implement ICCC and extended window manager hints specs correctly and
exactly as intended, that one could run in a bare Xnest environment,
would be ideal as a reference... Is there a such?

 > We are still experiencing the exact same problems described in
 > Inkscape.

Yes, I know.

FYI, in GIMP the issue with window transient-for relationship is even
more complex because GIMP plug-ins run as separate processes. (And
this is not likely to change soon.) In most cases GIMP wants to make a
dialog window created by a plug-in process transient for a window
created by the main GIMP process. And then again, the plug-in can ask
the GIMP process to create a dialog window which should be transient
for the one created by the plug-in. I.e. both cross-process
transiensent-for-ness (transience?) and chained transient-for... I
assume cross-process transience at least will be rather impossible to
implement correctly in gdk/win32. But, if I recall correctly, the
Reilly patch doesn't take in-process chained transient-for into
consideration either.

BTW, I don't know if this gtk-win32-list mailing list, which is quite
new, is the best place to discuss this. The description of the list
says "win32 platform building and packaging discussion", so is this
discussion about the *implementation* of GTK+ on Win32 even on-topic
for this list? Wouldn't gtk-devel-list be a better place?

--tml




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]