Re: RFC version issues

[muppet <scott asofyet org>]

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>