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

[Vincent LADEUIL <v ladeuil alplog fr>]

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

    muppet> On Oct 26, 2004, at 6:14 AM, Vincent LADEUIL wrote:

    >> 'get_selected_indices' is not implemented in Simple::Tree.

    muppet> get_selected_indices()   returns  a   flat   list  of
    muppet> integers which are  indices into a single-level list.
    muppet> this doesn't  make much sense in  a multi-level tree,
    muppet> hence, it's not implemented.

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> something  like  it  could  be  made,  but  it  would
    muppet> necessarily have to return different data (possibly a
    muppet> list of  TreePaths or TreeIters),  making it somewhat
    muppet> less Simple.


Keep it  Simple then :o)

    >> On a different topic, I have defined a new CellRenderer:
    >> CellRendererTextCompletion, derived from CellRendererText
    >> which implements completion functionality.
    muppet> [snip]
    >> - define a property for the renderer. Looks like only
    >> columns can be used. In the case of a completion, this is
    >> inadequate.

    muppet> if you mean a TreeViewColumn attribute, then yes,
    muppet> that's how it works.

We agree.

    >> - try to define a 'new' subroutine. Can't get it to work,
    >> I don't understand why S::(L|T) can inherit from
    >> Gtk2::TreeView via a simple ISA but CellRendererText
    >> insist on using the Glib::Object::Subclass mechanism.

    muppet> because if you  want to create new signals/properties
    muppet> or  override   C  vfuncs,  you   *must*  replace  the
    muppet> GTypeClass with your own at the C level

<snip/>

Clear.

    muppet> the  basic problem is  that the  CellRenderer methods
    muppet> RENDER,  START_RENDERING,  etc,  are virtual  methods
    muppet> called from  deep within gtk+.  gtk+ looks up  what C
    muppet> function  to call  in the  GTypeClass  (essentially a
    muppet> vtable)  of the CellRenderer  instance.  if  you just
    muppet> use normal  perl derivation for  the subtype, there's
    muppet> no way to route that call through your perl code.  by
    muppet> using   Glib::Object::Subclass,  a  new   GType  gets
    muppet> created for your object,  and that GType carries with
    muppet> it a vtable that  marshals those virtual method calls
    muppet> to perl.

Also clear.

    muppet> SimpleList/SimpleTree  don't  do  this  because  they
    muppet> don't need to -- because your perl code initiates the
    muppet> relevant  method  calls.   custom  CellRenderers  and
    muppet> TreeModels  simply will  not  work without  Subclass,
    muppet> because  the  perl  code  you  want  called  must  be
    muppet> triggered from C.

The missing bits ! 

Ok, I understand the principle,  now I have to match it every time
: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.

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

    muppet> you can still define a new() for your CellRenderer
    muppet> class, 

But  when I  tried to  define such  a subroutine,  it  looks like
either  she didn't  get  called  or the  object  was not  created
correctly. I stop testing this approach but I can spend some more
hours on it if you think it *should* work.

    muppet> but SimpleList/SimpleTree will not pass parameters to
    muppet> it.

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

    >> In the end, I just build an SLT, access the renderer, set
    >> the completion model, and associate it to the underlying
    >> Entry widget in START_EDITING. I just wonder if things can
    >> be done more efficiently.

    muppet> you  do  need  to  create  a  new  editable  in  each
    muppet> invocation of START_EDITING,  so that's alright.  you
    muppet> could   avoid  common   work  by   placing   that  in
    muppet> INIT_INSTANCE or  set_completion_model().  in fact, i
    muppet> see that you load a PhD::TBL, but don't see where you
    muppet> use it; is that something important?

Sorry, I missed  that when cleaning code. Forget  it, it predates
set_completion_model,  it was  just a  quick and  dirty  trick to
test. The completion model is a ListStore as required, built from
a list of strings.

    muppet> also, do you really want to use the same completion
    muppet> model for every row in a column? 

No. The completion model is specific to each column.

    muppet> how are you creating that model?

my $ls = Gtk2::ListStore->new('Glib::String') ;
$ls->set($ls->append,0,'ALL') ;
map {$ls->set($ls->append,0,$_)} qw{foo bar baz};

    muppet> is   it   something   that   could   be   placed   in
    muppet> INIT_INSTANCE,  or are you  filling it  with external
    muppet> data?

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

        Vincent