Re: Help! Custom cell renderers blowing up ...

2013-02-22 Thread Torsten Schoenfeld

On 22.02.2013 06:18, Dan Kasak wrote:

Hi Torsten. Thanks, once again, for the reply.


Glad to help.


On Thu, 2013-02-21 at 09:39 +, Torsten Schoenfeld wrote:

On 21.02.2013 07:28, Dan Kasak wrote:
> Can't locate object method "EDITING_STARTED" via package
> "Gtk3::Ex::Datasheet::DBI::CellRendererText" at
> /usr/lib64/perl5/site_perl/5.12.4/Gtk3.pm line 228.

I don't get this with my Gtk3 port of odot, so… no clue off-hand.  Can
you provide a self-contained example program exhibiting this?


Done. By the way ... perhaps an easier way of me getting this working is
to look at your Gtk3 port of odot ;)


Yeah, I'm in the process of putting it up somewhere.  I'll let you know 
when it's available.



> use Glib::Object::Subclass
>Gtk3::CellRendererText::,
>properties => [
>  Glib::ParamSpec->object(
>  "editable-widget",
>  "Editable widget",
>  "The editable
> that's used for cell editing.",
>
> Gtk3::Ex::Datasheet::DBI::CellEditableText::,
>  [ qw( readable
> writable ) ]
> ),

Do you need this property?  It was a hack in Odot, and I've now removed
it.  If you don't need it, you can also consider moving the creation of
the editable from INIT_INSTANCE to START_EDITING.


H ... The only way I've seen a custom CellRendererText working is by
implementing a CellEditableText, as per your previous example. Perhaps I
don't need it? I didn't do it on purpose ... just pulled in example code
and tweaked until it worked.


I wasn't referring to the custom cell editable per se, but to this 
specific property on the cell renderer.  In odot I needed it because 
originally the main part of the program needed to connect signal 
handlers to the cell editable even though it usually only has access to 
the cell renderer.  The cell editable is usually internal to the cell 
renderer.  I've now restructured things a bit so that the main program 
doesn't need access to the cell editable anymore, hence I could remove 
this property.


But you might not even need the custom cell editable at all.  The only 
reason for its existence in odot is to support editing multi-line text 
cells.  If you only have single-line text, you can use Gtk3::Entry 
directly (it implements the Gtk3::CellEditable interface already, unlike 
Gtk3::TextView).

___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list


Re: Help! Custom cell renderers blowing up ...

2013-02-22 Thread Dave Howorth
Dan Kasak wrote:
> On Fri, 2013-02-22 at 05:18 +, Dan Kasak wrote:
> 
>> Hi Torsten. Thanks, once again, for the reply.
> 
> AHA! Removed some distro libraries and pulled in via cpan ... and it's
> FIXED!

In most distros at least, you shouldn't need to remove distro libraries
(assuming you mean perl modules installed from distro RPM/DEB). In fact,
it can be dangerous to do so since some system utilities rely on those
versions. If you just install libraries using cpan in addition to those
already present through your distro package manager, things will just
work. Perl has multiple search paths and they're set up to make this
magic happen.
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list