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

["muppet" <scott asofyet org>]

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.

oh.  that's a bug.  :-)


> 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.

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

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

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

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

this is the paradigm you should usually follow when using
Glib::Object::Subclass --- your object should be reasonably functional without
overriding new().  why?  because subclassers are not forced to chain up to
your constructor!  you should do all relevant initialization in INIT_INSTANCE,
and provide object properties (optionally with setters and getters) for the
things the user of your code can set.


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

   sub new {
       my ($class, $something) = @_;
       # we can't do $class->new(), because we're overriding that.
       # 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.
       return Glib::Object::new ($class, something => $something);
   }

but, if you think about it for a while, that's actually not a great idea, and
it would be better to use the stock new().  this is one of the rough spots
where the paradigms of GObject and perl clash somewhat, and the intricacies of
GObject derivation and instantiation stem from that clash.


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

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




>     >> Anyway as SLT only provide a way to define the *type* of
>     >> the renderer and not an instance or a sub returning an
>     >> instance of a renderer...
>
>     muppet> the callback approach would be pretty interesting; at
>     muppet> the  risk of feature  creep, we  could have  the tree
>     muppet> construction code check whether the renderer type key
>     muppet> is ref($val) eq 'CODE'...
>
> That was  the idea,  but I  hesitate to propose  it in  the first
> place  because I  didn't know  which weight  you had  put  in the
> 'Simple' word.

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

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

  my $model = Gtk2::ListStore->new ('Glib::String');
  my $view = Gtk2::TreeView->new ($model);
  # set up the view columns and renderers as you like

  # tie the model to an array for easy access
  my @data;
  tie @data, 'Gtk2::Ex::Simple::TiedList', $model;

  # now put data in the model
  push @data, qw(fee fie foe fum);



> It's filled with external data. The data do not change during the
> Simple::List lifetime.  So my hope was to be able to give it as a
> parameter at Simple::List build time instead of doing :
>
> my $list = Gtk2::Ex::Simple::List->new_from_treeview(blah blah blah)
>
> my $column = $list->get_column(index for a completion column) ;
> # Only one renderer
> my $cell_renderer = $column->get_cell_renderers;
> $cell_renderer->set_completion_model($ls) ;

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


-- 
muppet <scott at asofyet dot org>