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

[muppet <scott asofyet org>]

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

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

get_selected_indices() returns a flat list of integers which are 
indices into a single-level list.  this doesn't make much sense in a 
multi-level tree, hence, it's not implemented.  something like it could 
be made, but it would necessarily have to return different data 
(possibly a list of TreePaths or TreeIters), making it somewhat less 
Simple.


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

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


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

because if you want to create new signals/properties or override C 
vfuncs, you *must* replace the GTypeClass with your own at the C level; 
this is what Glib::Object::Subclass does for you, and what conventional 
perl object derivation cannot do.

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

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


you can still define a new() for your CellRenderer class, but 
SimpleList/SimpleTree will not pass parameters to 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...

the callback approach would be pretty interesting; at the risk of 
feature creep, we could have the tree construction code check whether 
the renderer type key is ref($val) eq 'CODE'...


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

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

also, do you really want to use the same completion model for every row 
in a column?  how are you creating that model?  is it something that 
could be placed in INIT_INSTANCE, or are you filling it with external 
data?

--
"that's it! you're a genius!"  "yes.  that's what i think.  do you 
think i deserve a raise?"
        - dialogue from 'Godzilla versus Mothra', 1964