Re: Gnome2::PanelApplet [Re: Applets]

On Fri, 2007-02-02 at 09:38 +0000, Emmanuele Bassi wrote: 
On Thu, 2007-02-01 at 20:48 -0500, muppet wrote:
On Feb 1, 2007, at 8:46 AM, Emmanuele Bassi wrote:

until Gnome2::PanelApplet works, no: there's no other option.

*hint* fixing Gnome2::PanelApplet would be nice. ;-)

So, um, what exactly is wrong with Gnome2::PanelApplet?

short answer: don't really know.

long answer: who knows?

slightly longer answer: it's been a while since I've been able to devote
time to Gnome2::PanelApplet, but as far as I understand, you can't get
the bonobo activation server to run the perl process and attach the
widget to the panel process.  due to the fact that panel applets are a
pain to debug, I've been unable to understand why it fails, let alone
where it fails.

the error reported had something to do with gconf - meaning that the
applet died before the panel could save the applet data inside its own
gconf configuration path.

last time I discussed this was in 2005, with the panel and the applets
maintainers, and both were puzzled as I was.

a way to enhance debugging might be writing a dummy C applet and a perl
applet with the same factory name; attach the C applet to the panel,
kill it and when the panel asks you to reload it launch the perl applet
and then say yes to the reload dialog.  at that point, the perl applet
should print stuff to the terminal in which you launched it.  at least,
you would have debug messages.

I'm not sure that it needs to be that complicated (but my knowledge of
Bonobo and how it works is close to zero so feel free to ignore me).

Normally when you add an applet to a GNOME panel, the applet process is
kicked off in the background by the Bonobo framework, but ...

for debugging purposes, you can start your applet process manually from
a shell prompt (presumably you could even run it in a debugger).  It
will appear to hang, until you add the corresponding applet to the
panel.  At that point the Bonobo framework will 'attach' to your
existing process which can happily print debugging messages to
STDOUT/STDERR and they'll appear in your terminal.

I found that to be invaluable when debugging SSHMenu.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]