Re: listener question

Michael Meeks wrote:
On Mon, 2003-11-10 at 21:45, William Jon McCann wrote:
I think one way to handle this is to:
 1. poll bonobo_activation_query for an active event source
 2. attach listener to event source
 3. process notification events
 4. [event source destroyed] remove listener and goto 1.

	Right; the problem is: getting notifications of newly registered
components with b-a-s is not possible, something we could/should add to
b-a-s I guess.

OK, that explains some things. I couldn't get successive calls of the following to pick up changes: bonobo_activation_query ("((repo_ids.has('IDL:GNOME/Rhythmbox:1.0')) AND (_active == TRUE))", NULL, &ev);

But I was able to with the command line tool:
/usr/bin/bonobo-activation-run-query "((repo_ids.has('IDL:GNOME/Rhythmbox:1.0')) AND (_active == TRUE))"

I thought I was going crazy.

This seems like it could be a very useful enhancement. What would be the best way to do it? What files should I look at?

It would be great if I didn't have to do any polling at all. One notification that an event souce became available. One notification that an event source died.

Is there a better way to do this?  If not, what is the best way to do 4?
   Is there a signal emitted when the event source is destroyed?

	Well; you can use the ORBit_small_[un]listen_for_broken API, it's a
slighty clumsy thing though.

I'll take a look at it.  Thanks.

	An alternative may be to have your application contact the applet to
set properties on that instead - that is assuming you control both ends
of the pipe :-)

I'm not sure that helps. There is another use case where the applet is created after the application is started. I think getting notifications of newly registered components is the only way out.


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