Re: [Perlpanel-devel] catching applet exceptions

[Gavin Brown]

Moshe wrote:

> As I wrote in another mail, I think perlpanel has a problem with 
> exceptions caused in the applets code.
> Naturally, not all applets handle all exceptions that arise in their 
> code. When such an exception happens, it crashes the whole panel. This 
> is unfortunate, especially since there is always new applet code to 
> test.

I think this is less of a problem for a "standard user", who will only
use the applets that ship with PerlPanel. It is my hope and aim that all
the applets behave well regarding exceptions, so that such a user will
never see one.

As for those people testing new applet code, I hope they'd find the
crashes annoying enough to fix the code :p

> I believe there is a way to solve it, but I don't know enough about 
> gtk/glib to know for sure: As far as I understand, all applets are 
> children of an hbox. What I thought is to put this hbox inside a 
> Gtk2::EventBox. Now, this widget has a method set_above_child, which 
> allows it (as I understand it) to get all signals (button clicks, etc.), 
> instead of the hbox. This EventBox will then pass the signal to the hbox 
> child inside an eval block, thus trapping exceptions that occur in the 
> callbacks. In addition, all methods such as configure, 
> get_default_config, etc. should also, of course, be called inside an 
> eval.

I agree absolutely about the configure() and get_default_config() calls,
and I will probably sort that out today.

As for the event box magic, I'm pretty sure that your proposal wouldn't
reliably work, since an error be raised at any moment (due to a
Glib::Timeout, or a thread or any other of the asynchronous ways that
Perl can do stuff) and might not necessarily be captured by gtk2-perl's
exception system.

It's definitely something worth thinking about though. gnome-panel's
approach is to run a lot of the applets as separate processes and use
XEMBED, but I'm not a big fan of that technique, since it clutters up
'ps'.

> The only thing is, I don't know if it's possible to install a "universal 
> callback" for all signals, and how can one pass the signal to another 
> widget.

There is the 'event' signal, but I've never been able to do anything
useful with it. Attaching a handler to it just seems to freeze the
application.

Gavin.

-- 
Gavin Brown
e: address@hidden
w: http://jodrell.net/
PGP/GPG key ID: 891D8FCA