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

[Vincent LADEUIL <v ladeuil alplog fr>]

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

    muppet> Vincent LADEUIL said:
    >> Sorry, should have made myself clearer: The example script
    >> simple_tree.pl calls the unimplemented
    >> get_selected_indices. I didn't need it myself.

    muppet> oh.  that's a bug.  :-)

:o)

    >> Now, can you tell me why I can't add a subroutine called
    >> 'new' which act as a constructor when I use the
    >> Glib::Object::Subclass approach.

    muppet> how are you writing your new()?  a traditional perl
    muppet> "bless {}, $class" won't work, because you have to
    muppet> trigger the underlying call to g_object_new().

The missing bits, again :o) I search for that, but failed :-/

    muppet> the new() supplied by Glib::Object::Subclass
    muppet> (actually Glib::Object::new()) allows you to use a
    muppet> perlish construction idiom (named parameters), so
    muppet> long as your class defines a GObject property for
    muppet> each thing you want to set.  for example, in
    muppet> histogramplot.pl
    muppet> (http://gtk2-perl.sourceforge.net/doc/examples/histogramplot.pl.html),
    muppet> the driver code instantiates the widget with

    muppet>    my $plot = Histogram::Plot->new ( threshold => 64,
    muppet> histogram => [ map { sin $_/256*3.1415 } (0..255) ],
    muppet> );

I try all  the examples one by one with  no particular purpose in
mind. When I  encounter this one, I said  to myself: "Nothing for
me here" and pass along... :)

    muppet> but there  is no new() defined in  the derived class;
    muppet> the class uses Glib::Object::new(), which treats each
    muppet> parameter  pair  as  a call  to  Glib::Object::set().
    muppet> 'threshold'  and  'histogram'  are object  properties
    muppet> defined     in    the     import     arguments    for
    muppet> Glib::Object::Subclass.

...and the  missing link !  Ok, things are  clear now (did  I say
that before ? :o)

    muppet> this is the paradigm you should usually follow when
    muppet> using Glib::Object::Subclass --- your object should
    muppet> be reasonably functional without overriding new().
    muppet> why?  because subclassers are not forced to chain up
    muppet> to your constructor!  

Yeah,  the limits  of  mixing two  OO  paradigms... As  far as  I
understand the  limits, you still  did a wonderful job  with Gtk2,
I'm still  impressed by the  ease of use  and the perlish  way of
doing things...

    muppet> you   should  do   all  relevant   initialization  in
    muppet> INIT_INSTANCE,   and    provide   object   properties
    muppet> (optionally with setters  and getters) for the things
    muppet> the user of your code can set.

Enlightment !   I was under  the impression that  properties were
column indexes for GtkTreeViewColumns,  but that was just the way
they were used in Mup::CellRendererPopup ! Silly me !

    muppet> given all that, if you *still* want to create your
    muppet> own new() (e.g., to have a "convenience constructor"
    muppet> like the ones used by most gtk+ widgets, you'd do it
    muppet> like this:

   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 ?


       # 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)

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


       return Glib::Object::new ($class, something => $something);
   }



    >> And can you confirm that I am still free to add any fields
    >> in the blessed hash (except when they are already used).

    muppet> yes.  

Good.

    muppet> the GObject  and the Perl object are  tied with magic
    muppet> (yes, that's the technical  term :) 

;)

    muppet> under the hood to ensure that you will always see the
    muppet> same  perl  reference   for  the  same  GObject  (and
    muppet> vice-versa), and the data  you place in the hash will
    muppet> stay  with  the object.   the  normal warnings  about
    muppet> reference-count  cycles in  perl data  structures are
    muppet> critically important with Gtk2-Perl.

Hmmmm, rings a bell...

http://www.catb.org/~esr/jargon/html/koans.html#id3141202

One day  a student came  to Moon and  said: "I understand  how to
make a better  garbage collector. We must keep  a reference count
of the pointers to each cons."

Moon patiently told the student the following story:

    "One day a  student came to Moon and  said: `I understand how
    to make a better garbage collector...

    muppet> personally, i  feel that when it  starts getting this
    muppet> complicated,  it's no longer  worth using  the Simple
    muppet> modules  --  it's  actually  harder to  document  and
    muppet> maintain  than  just   using  the  raw  MVC  TreeView
    muppet> directly.    however,   i'm   not   maintaining   the
    muppet> Gtk2::Ex::Simple stuff, so i'll  leave it for ross to
    muppet> decide on such a feature.

I  agree,  I  can't find  a  solution  which  do not  render  the
interface complicated :(

    muppet> i seem to recall a proposal to break the tied model
    muppet> stuff out separate from SimpleList to allow you to
    muppet> still have simple tied data access with complex,
    muppet> hand-created views... something like this should
    muppet> work:

Thanks.

    muppet> the way i see it, that's pretty much your only
    muppet> option.

Ok,  thanks a  million  for that,  I  am already  happy with  the
present available solutions, and you clarify my other concerns,

        Vincent