Re: RFC version issues
- From: muppet <scott asofyet org>
- To: Murray Cumming Comneon com, Gtk-Perl-List <gtk-perl-list gnome org>
- Subject: Re: RFC version issues
- Date: Fri, 23 Jan 2004 09:19:28 -0500
On Friday, January 23, 2004, at 08:47 AM, Ross McFarland wrote:
On Fri, 2004-01-23 at 07:57, Murray Cumming Comneon com wrote:
Because GTK+ never breaks ABI, there is no reason why people can't
upgrade
their GTK+ if they want to get new features or important bugfixes in
newer
version of gtk-perl.
other bindings can require upgrades of everything just to get bug fixes
for themselves if they wish, we haven't and aren't going to do that.
we're not putting the burden on users, the easier we make things the
better our bindings will be and the more they will be used.
namely, we don't have time to maintain three branches to support 2.0.x,
2.2.x, and 2.4.x, backporting new bugfixes and documentation system
features to each one. we get testing on all three platforms gratis by
virtue of the fact that my company has installed a whole slew of redhat
8.0 boxen that it probably won't upgrade for a couple of years. i need
to be able to use the bindings in the meantime, and i want to use the
latest and greatest bindings.
what does gtkmm does? this is/should be an issue for all of
the binding sets not just gtk2-perl although i don't remember
seeing anyone else even trying to handle it.
gtkmm 2.0.x works with GTK+ 2.0, 2.2 and 2.4. It has the same API
however
you configure it.
gtkmm 2.2.x works with GTK+ 2.2 and 2.4. It has the same API however
you
configure it.
gtkmm 2.4.x will work with GTK+ 2.4. It has the same API however you
configure it.
Gtk2 1.023 works with 2.0, 2.2, and will work with 2.4. its API
supports whatever gtk+ version you compile it against. for binary
packages and distro maintainers, that simply means setting up
dependencies correctly, which is very easily resolved on the user's
end. i don't see the problem, but perhaps i'm looking in the wrong
place.
if i run gtkmm 2.0.x with gtk+ 2.4 (as you say is supported) what does
get_version_info return to me? if it returns 2.4.x then apps written to
use specific features depending on get_version_info will fail b/c
they'll be getting that it's 2.4.x, but since they're running gtkmm
2.0.x the new features won't be bound. that's the issue here, not the
numbering scheme.
for clarification, suppose i write an app that i want to use spiffy new
features of gtk+ if they are available, but fall back gracefully if
they aren't:
if (ret = gtk_check_version (2,4,0)) {
/* returned a string containing mismatch information */
g_warning ("gtk+2.4 not available, falling back to GtkItemFactory");
...
} else {
g_warning ("gtk+2.4 is available, using GtkUIManager");
...
}
the problem here is that gtk_check_version () (the function used by
Gtk2->check_version) compares the values you supply with the versions
in the gtk+ shared library that is currently linked at runtime. so if
you have an old version of the binding and a new version of gtk+,
check_version tells you that you have something your binding doesn't
actually support.
this particular fallback situation is less likely to happen with gtkmm
because it gets symbol resolution at link time, so an app would have to
decide this at compile time to allow the program to link, and you
probably use the GTK_CHECK_VERSION macros to do it. (an old gtk+/gtkmm
wouldn't have the UIManager stuff to link against, so you'd have to
dlopen them for this to work, and who wants to do that?)
for perl we compile and link long before the user gets a crack at us,
so we enable everything we can, and allow the script to decide at
runtime.
--
muppet <scott at asofyet dot org>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]