Re: Living on the bleeding edge (a bug report)
- From: Bjarne Steinsbø <bosteins broadpark no>
- To: muppet <scott asofyet org>
- Cc: gtk-perl-list gnome org
- Subject: Re: Living on the bleeding edge (a bug report)
- Date: Mon, 03 Nov 2003 21:18:28 +0100
muppet wrote:
Bjarne Steinsbø said:
if you're going to use gtk+ 2.3.x, i recommend lurking on the
gtk-devel list
to stay abreast of new happenings.
I might do that, or maybe just look at the change log once in a while to
see if anything interesting has been commited.
I'm truly impressed by the quality of these "unstable" releases, btw.
That goes for perl-gtk also.
what do you say to returning a string like "2.3.0" in scalar context, and the
list of elements in list context?
Sounds good to me. I was about to suggest using a perl version string
(like "v2.3.0") until I re-read the perl docs and saw that version
strings are beeing deprecated. According to
http://search.cpan.org/~jpeacock/version-0.32/lib/version.pm (at least
the way I read it), a quoted string is the best solution while waiting
for perl-5.10.
speaking of that being absent in the bindings, support for 2.3.0 adds 21 new
files to Gtk2. i have these on deck on my home machine, waiting to go into
cvs as soon as i get the build on HEAD ready to make a branch to support
2.3.x. before you ask why i'm not supporting 2.3.x on HEAD, it's because
2.3.x is not guaranteed to be API stable, and i want only bindings for stable
gtk+ on HEAD (even if HEAD isn't always stable). stay tuned, i'll have this
stuff in soon, i swear.
Looking forward to it. My eyes are still on the treeview stuff, and
there's now a filter that can be applied to the model. I'm not sure how
easy this will be to use from perl, though, increasingly it seems that
gtk+ implements new "interface"s for new and advanced stuff, and I
really miss being able to subclass any kind of gtk+ class and override
even vtable-methods. I've now spent hours and even days trying to find
a good way to listen in to dnd-operations on tree-models, but had to
give up in the end because I found no reliable way to determine the drop
point without overriding the drag_data_received method in
Gtk2::TreeDragDestIface.
Bjarne
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]