Re: Gtk2 CellRendererText: how to save the edited value in the cell?

I've found a solution of sorts:

subclass Gtk2::CellRendererText, and patch its START_EDITING method to emit the 'edited' signal when the embedded entry receives a 'focus-out-event'.

package Gtk2::CellRendererTextThatIsNotCompletelyUseless;

use Glib::Object::Subclass "Gtk2::CellRendererText";

sub START_EDITING {
    my ($self, $event, $view, $pathstr, $back_rect, $cell_rect, $flags
+) = @_;

    my $entry = shift->SUPER::START_EDITING(@_);

    $entry->signal_connect(
      'focus-out-event' => sub {
         my ( $event_box, $event ) = @_;
         $self->signal_emit( edited => $pathstr,   $entry->get_text() 
+);
         return 0;
      }
   );

    return $entry;
}

1;
[download]

Not elegant, but it appears to work.

I'd also like to nominate the previous reply to this thread to the 2017 Contest of Most Helpful and Well-Considered Forum Replies (and grumble that this place is not what it used to be).

Comment on Re: Gtk2 CellRendererText: how to save the edited value in the cell? Download Code

Replies are listed 'Best First'.

Re^2: Gtk2 CellRendererText: how to save the edited value in the cell?
by kikuchiyo (Hermit) on Nov 16, 2017 at 18:35 UTC

Ehh, not perfect. If the user clicks out of the cell but in the listview, the edited signal will fire twice (once normally, once thanks to the hackery above).

Modified version:

package Gtk2::CellRendererTextThatIsNotCompletelyUseless;

use Glib::Object::Subclass "Gtk2::CellRendererText";

sub START_EDITING {
    my ($self, $event, $view, $pathstr, $back_rect, $cell_rect, $flags
+) = @_;

    my $entry = shift->SUPER::START_EDITING(@_);

    $self->signal_handler_disconnect($self->{bad_hack}) if exists $sel
+f->{bad_hack};

    $self->{bad_hack} = $self->signal_connect(
      'editing-canceled' => sub {
         my ( $event_box, $event ) = @_;
         $self->signal_emit( edited => $pathstr,   $entry->get_text() 
+);
         return 0;
      }
   );

    return $entry;
}
[download]

The appropriately named bad_hack abuse is needed to avoid connecting the signal handler again and again - but we can't just install it once and leave it be, because the anonymous sub closes over $entry, which refers to the Gtk2::Entry that is destroyed and recreated every time the user starts editing, so the need a new handler with a new closure of the newly created $entry every time.

I feel a slight sting that there is a better way to do this, I just don't see it.

[reply]
[d/l]


There's more than one way to do things
	PerlMonks