[xs] Gtk2->input_add / Gtk2->input_remove

[Jörn Reder <joern zyn de>]

Hiho,

the current Gtk2->input_add wrapper is broken (as mentioned in the 
source ;). I decided to check the docs and to use the new interface, but
ran into a strange problem resp. learned, that adding an IO watcher with
Gtk 2.x indeed isn't not as easy as in Gtk 1.x.

Gtk 1.x called the callback also for the eof() / pipe close events, but
Gtk 2.x doesn't. To achieve the same behaviour you need to connect the 
G_IO_HUP event also (and check for eof() in your callback, as with 
gtk-perl). If you don't do that the G_IO_HUP event may be emitted 
infinitely (when a pipe program executed early) and the process consumes
95% CPU. Also the connected 'read' callback is never called.

I think that's another argument for having the simple Gtk2->input_add 
interface, although it's deprecated. I found the following 
implementation is working for me. It's still somewhat different to the 
gtk-perl implementation, in particular $data is @data in gtk-perl - I 
found no easy solution for that. Also a hash ref containing both 
G::Source id's is returned, instead of a single scalar:

    sub input_add {
        shift; # lose the class
        my ($fd, $condition, $callback, $data) = @_;

        use Carp;
        # map 'read' and 'write' to the correspondent GIO enums
        $condition =
                $condition eq 'read'  ? 'G_IO_IN'  :
                $condition eq 'write' ? 'G_IO_OUT' :
                croak "Invalid condition flag. Expecting: 'read' / 'write'";

        my $tag = {
                io_id  => G::IO->add_watch ($fd, $condition, $callback, $data),
                hup_id => G::IO->add_watch ($fd, 'G_IO_HUP', $callback, $data),
        };

        return $tag;
    }

    sub input_remove {
        shift; # lose the class
        my ($tag) = @_;

        my $rc_io  = G::Source->remove ($tag->{io_id});
        my $rc_hup = G::Source->remove ($tag->{hup_id});

        return ($rc_io && $rc_hup);
    }

Having a hash ref as the input tag is somewhat clumsy. I'm not sure, if
we really should offer this API redirection stuff here. Probably 
croaking a recipe of doing it right may be a cleaner solution ;) Should
I commit it? Or do we throw away the whole deprecated wrapper stuff?

Regards,

Joern

-- 
Think, before you code.