Now that a single shared object can contain multiple backends we also
need to provide a simple way for third party code to verify that the
copy of GDK they are linking to supports their backend.
The simplest way to verify is an m4 macro, GTK_CHECK_BACKEND(), shipped
with the gtk+ m4 macros.
The usage is pretty basic:
GTK_CHECK_BACKEND([x11], [gtk_has_x11=yes], [gtk_has_x11=no])
AM_CONDITIONAL(BUILD_X11_CODE, test "x$gtk_has_x11" = "xno")
https://bugzilla.gnome.org/show_bug.cgi?id=642479
At the same time, change the library sonames for -3.0 to just -3.
This is necessary since the 2.99 releases installed libraries like
libgtk-3.0.so.0.9903.0, and we want to prevent the library version
number from jumping back. So 3.0 will have libgtk-3.so.0.0.0.
The previous function gdk_drag_get_protocol_for_display() took native
window handles, so it had to be changed. Because it didn't do what it
was named to do (it didn't return a protocol even though it was named
get_protocol) and because it doesn't operate on the display anymore but
on the actual window, it's now called gdk_window_get_drag_protocol().
... and all APIs making use of it.
That code like it hasn't been touched in years, Google codesearch
didn't find any users and most importantly it's a horrendous API, so
let's just make it die instead of having to port it over to
non-GdkNativeWindow usage, which would be required for multi-backend
GDK.
http://mail.gnome.org/archives/gtk-devel-list/2011-January/msg00049.html
I think it's confusing for a lot the developers out there who
may not even be aware of GTK+ 3 coming, if suddenly GTK+ 3 becomes
the "stable" version of "gtk" on library.gnome.org. It may
not even be feasible for them to port to GTK+3 if it's not
shipped in the operating systems they're targeting (for example,
RHEL 6).
Since practically speaking, we expect people to consume GTK+ 2 for
several years at least, redirect these people to the right pages.
(I didn't attempt to explain the differences between the libraries
here, but hopefully the major version difference is enough of a hint)
As a side effect, this makes the generated HTML look better; previously
it looked rather crappy, since the "for GTK &version;" was totally
offset and in a different group from the documentation title.
Also added documentation section for this. Since the GtkRecentFilter
documentation was still living in sgml, as a side-effect I migrated these
docs to the gtkrecentfilter.[ch] sources.
