Ripping out GLib bindings, depending on GLib

[Andreas Rottmann]

Hi!

In order to increase method creation time in the huge GTK+2 binding,
I'm going to follow the advice from Mikael Djurfeldt and bundle
creation of all methods for one generic into one call. I thus need to
collect all the methods for each generic in the wrapset. I right now
have started implementing this using GHashTable. This imposes the
following questions/implications:

1) Is it reasonable for g-wrap to depend on GLib?

2) It's not possible combine usage of GLib 1.2 and 2.X. Since g-wrap
   comes with a GLib 1.2 binding (which is superceded by the GLib 2.X
   in guile-gobject). This means I either can't use GLib in the core
   g-wrap, if I want guile-gobject stay operational, or rip GLib
   binding stuff (along with the GTK+ 1.2 binding) out of g-wrap. I
   definitely favor the latter.

While writing up 2), I wondered if this is a reasonable point for a
g-wrap version fork: Release g-wrap 1.3.4+fixes as g-wrap 1.4.0 and
start a 1.5 branch with my modifications/extensions. I guess it is not
feasible to drop the GLib 1.2 binding in the 1.3 series, since gnucash
(still) depends on it.

Regards, Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Say NO to Software Patents! -- http://petition.eurolinux.org/