Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

"onClose" for multiple Gtk2::Notify objects

by AltBlue (Chaplain)
on Jan 28, 2007 at 07:49 UTC ( [id://596951]=perlquestion: print w/replies, xml ) Need Help??

AltBlue has asked for the wisdom of the Perl Monks concerning the following question:

Playing with desktop notification candies, I tripped over an annoying problem: how to properly use Gtk2::Notify in order to get appropriate closed signals for each such notification object?

Currently, all I get is only the signal for first notification.

Here's the test code:
#!/usr/bin/perl -l use strict; use warnings; use Time::HiRes (); use Gtk2::Notify -init, 'onCloseTest'; # testing 101: use "signal_connect" or "signal_add_emission_hook"? # - "signal_connect" sounds reasonable, but only first notification ge +ts it # - "signal_add_emission_hook" triggers "closed" signals way too early my $use_emission_hook = scalar @ARGV; # notifications cache my %notes = (); # generate some notifications for my $id ( 1 .. 3 ) { my $n = $notes{$id} = Gtk2::Notify->new( 'summary ' . $id, 'body ' . $id ); $n->set_timeout( $id * 1000 ); my $hook_method = $use_emission_hook ? 'signal_add_emission_hook' : 'signal_co +nnect'; $n->$hook_method( closed => \&closed, $id ); $n->show; print Time::HiRes::time, ' Showing note ', $id; } Gtk2->main; # "onClose" handler sub closed { shift if $use_emission_hook; # skip "hints" my ($n, $id) = @_; print Time::HiRes::time, ' Closing note ', $id; delete $notes{$id}; Gtk2->main_quit if !%notes; return; }

Sample output ("signal_connect"):

$ ./on-close.pl
1169969648.259 Showing note 1
1169969648.26891 Showing note 2
1169969648.2776 Showing note 3
1169969649.35453 Closing note 1

Use ^C to exit Gtk loop, as no signals will be received upon closing next notifications.

Sample output ("signal_add_emission_hook"):

$ ./on-close.pl 1
1169969850.63043 Showing note 1
1169969850.63678 Showing note 2
1169969850.6449 Showing note 3
1169969851.63109 Closing note 1
1169969851.63122 Closing note 2
1169969851.63133 Closing note 3

Closing too fast. Notification windows were not really closed yet when receiving those signals.

Environment details:

GNU/Linux 2.6.19
perl 5.8.8 (i386-linux-thread-multi)
glib 2.12.9
gtk2 2.10.8
dbus 1.0.1
libnotify 0.4.3
notification-daemon 0.3.6
Gtk2 1.142
Glib 1.142
Gtk2::Notify 0.02

TIA

UPDATES:
  • mention dbus version
  • switched <code> to <pre> in "output" blocks

Replies are listed 'Best First'.
Re: "onClose" for multiple Gtk2::Notify objects
by zentara (Cardinal) on Jan 28, 2007 at 11:26 UTC
    I don't have libnotify or d-bus-1 installed, it seems like pretty exotic stuff. Maybe you would be best off asking this on the gtk-perl-list

    I'm not really a human, but I play one on earth. Cogito ergo sum a bum
      Thanks for the feedback, indeed, I forgot to mention dbus in my "env" list.

      My experience with Gtk/Glib is - to say the least - very shallow, so I figured maybe I chose am "unnatural" approach for handling widget signals. That's why I preferred not to bother gtk-perl folks, keeping the discussion inside the monastery ;-)

Re: "onClose" for multiple Gtk2::Notify objects
by AltBlue (Chaplain) on Jan 28, 2007 at 22:37 UTC

    Sorry for the noise folks, I managed to fix it by using the current libnotify SVN revision.

    Quoting their changelog:

    * Fixed a bug where a notification's ID could be reset when a different notification was closed. Patch by jylefort. (Bug #94)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://596951]
Approved by wfsp
Front-paged by andyford
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (2)
As of 2025-07-12 06:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?
    erzuuliAnonymous Monks are no longer allowed to use Super Search, due to an excessive use of this resource by robots.