Re: Gtktree bug?

[Pozsar Balazs <pozsy sch bme hu>]

> > I don't really know what causes this. I did reproduce it, and I found that
> > if you remove the calls to set_sensitive in the callback ::
> >
> > sub on_tree_select_row {
> >            print "on_tree_select_row\n";
> >            my ($widget, $node) = @_;
> >
> > ===>       $gtktree->set_sensitive(0);
> > ===>       $gtktree->set_sensitive(1);
> >            print "RETURN\n";
> > }
> >
> > then the problem goes way. But why, I don't know.
> Hi, just a possibility but does set_sensitive(1) go and look for any
> outstanding events? If so you would have deeeeeep recursion

Sorry, I do not understand you. What deep recursion might occur?

> - perhaps
> if you signal_connect_after() there will be no outstanding events to
> recurse.
I tried it, but it doesn't help.

> I haven't tried either way as I don't really want to lock up
> my X server (no telnet to kill it).

It doesn't completely locks up X. You can move your mouse around,
ctrl-alt-Fx still works, and all you have to do is kill this process.

The most interesting (surprising) thing for me is when you look at the
strace output. You will see that the application still receives keyboard &
mouse events! (I guess that somehow it doesn't give it back to the X
server nor it handles them anymore).

Any more thoughts? Where should I post this?

For reference, here a short version of the offending code:
#!/usr/bin/perl
use strict; use warnings; use diagnostics; use Gtk '-init';

my $gtktree = new Gtk::CTree(1,0);
$gtktree->set_selection_mode('browse');
$gtktree->insert_node( undef, undef, [ "one" ], 5, undef, undef, undef, undef, 0, 0 );
$gtktree->insert_node( undef, undef, [ "two" ], 5, undef, undef, undef, undef, 0, 0 );
$gtktree->signal_connect_after("tree_select_row","on_tree_select_row");

my $w = new Gtk::Window; $w->add($gtktree); $w->show_all;

main Gtk;

sub on_tree_select_row {
        print "on_tree_select_row\n";
        $gtktree->set_sensitive(0); print "insensitive\n";
        $gtktree->set_sensitive(1); print "sensitive\n";
}
__END__

Notes:
1. signal_connect and signal_connect_after has the same effect.
2. You can see 'sensitive' on stdout, it somehow gets in the locked state
_after_ return from the signal handler.

thanks,
-- 
Balazs Pozsar.