muppet <scott <at> asofyet.org> writes: > Without a namespace change, we can't really ever remove things that > have been in stable releases. The reason is that doing so would break > existing code that we do not control. > > And, we've reserved the idea of moving to the Gtk3 namespace for the > bindings of gtk+ 3.x. > > So, Gtk2::Pango must always be there. > > The primary option is simply to yellow-wire[1] all of the Gtk2::Pango > APIs over to the new namespace, mark them deprecated in the docs, and > promote the use of the new stuff. See also our handling of > Gtk2::SimpleList and Gtk2::Ex::SimpleList, and Gtk2::CodeGen versus > Glib::CodeGen.
Agreed. If someone can pack up the new Pango dist with the xs moved over, I'm happy to do the namespace wiring to provide gtk2::pango compatibility. > Another option is to split all the Gtk2::Pango stuff into a second XS > extension installed by Gtk2; you'd have to have Gtk2 installed to use > Gtk2::Pango, but would not have to load it into memory. Not as clean, > and harder on the build infrastructure, but easier on the > compatibility issues. I think I'd prefer the standalone Pango dist, as the problem was first brought up because I wanted to use pango with cairo but not gtk2. > For the record, when all this got started, we assumed (wrongly, it > appears) that no one would want to use pango without gtk+. A > secondary reason was to avoid toplevel namespace pollution on CPAN. I guess pango at that time didn't have other stanealone uses (or not as popular as it is today), but it's never to late to fix things ;) Cheers, CLK _______________________________________________ gtk-perl-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-perl-list
