Re: Gtk2::Ex::Simple::(List|Tree)

[Vincent LADEUIL <v ladeuil alplog fr>]

> > > > > "muppet" == scott  <scott asofyet org> writes:

    muppet> On Oct 28, 2004, at 4:48 AM, Vincent LADEUIL wrote:

    >> The missing bits, again :o) I search for that, but failed
    >> :-/
    muppet> [snip]
    >> ...and the missing link !  Ok, things are clear now (did I
    >> say that before ? :o)
    muppet> [snip]
    >> Enlightment !

    muppet> do you have suggestions for where or how this should
    muppet> be explained in the documentation?

I keep rewriting  how to answer to that. I will  try to be simple
for now (and for a change :)

Imho, what  is missing is  an explanation on how  inheritance and
signal propagation are implemented in gtk (the C implementation),
and how  you implement  them in Gtk2.  I feel that  you perfectly
knows the details and often  warn the reader about the limits but
never give the full picture.

Well, let also say that I choose Gtk2 and glade and hope to write
an  application without  having  to  learn too  much  how gtk  is
implemented :)

    muppet> i think i am too familiar with it to understand fully
    muppet> how to explain it to the uninitiated -- at least, our
    muppet> current docs reflect that.

:-/ I understand that feeling.

... and I use  perl for nearly 10 years, and have  use C++ a good
10 years too. But I never had  to write an XS, and it looks like,
to fully  understand how Gtk2  works I need that  (comparing with
Perl/Tk, there was a lot more  done in perl and Data::Dumper on a
top level window revealed all the widget hierarchy...).

Note   that  pointers   to  related   documentations  in   the  C
implementation  are  perfectly valid  in  that  case  :) Or  even
pointers to the code !

I know it may not fully answer your question, but I will continue
to work on  the subject and try to come  back with something more
concrete.

    >> sub new { my ($class, $something) = @_; # we can't do
    >> $class->new(), because we're overriding that.
    >> 
    >> Don't get that >-/ Did you mean you can't do
    >> $class->new($something) or just that you had added a
    >> parameter ?

    muppet> perl method lookup is done purely at runtime, *after*
    muppet> the compile phase, and is done purely on name, not
    muppet> parameters (as in C++).  so in Foo::bar(), a call to
    muppet> Foo::bar() will resolve to the exact same function --
    muppet> you'll call yourself indefinitely.  Foo::SUPER::bar()
    muppet> will skip Foo::bar() while looking through @ISA for
    muppet> bar(), but i explained next why i decided not to do
    muppet> that.

Oh ! That ! Ok, I was searching something more complicated :-/

    >> # we could do $class->SUPER::new() if we knew its call
    >> signature.  # instead, i'll go straight to
    >> Glib::Object::new, because i know # it will call each
    >> INIT_INSTANCE in the ancestry to initialize # the object
    >> properly.
    >> 
    >> I'm sure I had already read that comment somewhere, I
    >> searched for it whereever I can think of, Gtk2 doc,
    >> tutorial, examples, can't put my finger on it ! Thanks so
    >> much :o)

    muppet> i would've sworn that was mentioned in either
    muppet> http://gtk2-perl.sourceforge.net/doc/pod/Glib/Object/Subclass.html
    muppet> or
    muppet> http://gtk2-perl.sourceforge.net/doc/subclassing_widgets_in_perl.html
    muppet> , but apparently i was wrong; it seems to be assumed
    muppet> or inferred.  it is explained in the gtk+
    muppet> documentation, but i doubt many perl programmers will
    muppet> read about the guts of doing OO in C.  ;-)

Ok. It was not exactly this comment, but it *was* in the tutorial
you    mentioned    on    sub    on_show,   above    the    call
"$self->signal_chain_from_overridden".

    >> But it means, that it works for only one level of perl
    >> inheritance isn't it ?

    muppet> GObject only allows single inheritance; that means
    muppet> one parent at a time, e.g., only one GObject in @ISA;
    muppet> GObject uses Interfaces in place of multiple
    muppet> inheritance, but the perl bindings just use perl's
    muppet> @ISA.

    muppet> you can, however, derive a new perl gobject from a
    muppet> perl-derived gobject; the Glib test suite verifies
    muppet> this.  everything is based on package names, and the
    muppet> fact that INIT_INSTANCE and friend are called from C
    muppet> when g_object_new() walks the ancestry.

Ok.

    muppet> wow, that's not very clear.

But everything you say help me understand better.

    muppet> sorry.

Be forgiven, it's a hard work ! :o)

        Vincent