Re: Gtk+ 2.3 ABI breakage or Gtk-Error **: incompatible build!

[Owen Taylor <otaylor redhat com>]

On Sat, 2003-11-01 at 13:57, Hans Breuer wrote:

> >> Further, isn't always true above_initially == !below_initially.
> >> So there would be only one flag needed ?
> >
> >No, that's not true - above is above all windows, below below
> >all windows.
> >
> Interesting, is this just a temporary state (initially?) so it
> does affect only the Z-order when the window is showm? Or should
> the window keep it state even when the user clicks on some other
> toplevel (i.e. _keep_above, or HWND_TOPMOST in windoze parlance) ?

I believe (look at the docs, and the freedesktop.org WM spec for
full details) it's a "keep above" state. The "_initially" part
there is a GtkWindow internals thing ... it's a flag saying that
when the widget is realized, we need to signal the windowing system
to keep above.

> >> But even fixing this won't give us back a compatiple ABI. Apparently
> >> some gobject has changed size as well (or at least I needed to recompile
> >> Pango as well to get a not crashing testfilechooser ...)
> >
> >I haven't seen any problems switching back and forth between GTK+-2.2
> >and GTK+-2.4 builds. So, it probably is some other MSVC specific
> >problem. Can you track it down?
> >
> If I fully understand the rules, I can try. But if I have done
> something unsupported it's probably not worth the effort.

It's probably not worth a lot of effort. But I think it might be
worthwhile to at least try installing Pango-1.2, and see if it's
crashing for an obvious reason.

I'm a bit curious how you are testing out testfilechooser, since
my expectation was that it would take substantial work to get
it to go on Win32. 

(To get it to go right, GtkFileSystem needs to be ported to the Win32
shell API, which requires a change to GtkFilePath, though something
simple  similar to GtkFileSystemUnix is probably possible.)

> As I understand every visible struct needs to keep it's size and
> even the bitfields need to keep their place. So the patch to
> gtkwindow.[hc] needs to be applied.
> 
> But is it really supported to mix like : newest GObject, newest Gtk
> with some older build of Pango laying around ? (This is what
> seems to have caused the other problem, and I'm not even sure
> what version of Pango it was ;-)

The bin-compat rules for Pango and GObject are the same as for GTK+...
binary compatibility shouldn't break ever; so I'd expect that
combination to work at the moment. (There are some new API additions
in Pango that we'll use in GTK+ shortly, so it won't continue to
work, but at the moment, I think it will work.)

Regards,
						Owen