Problems with observer-service?

[Marcio Galli]

It's been a while I have trouble with the observer service

Someone else also had problems?

What i do is:

ob  = require("observer-service");

then things like

 let cb = function () {
        console.log("app start is holy diver");
        // server.startP2PListener();
  }
  ob.add("final-ui-startup", cb);

And nothing happens...

--
blog.taboca.com

[Myk Melez]

On 08/11/2010 01:28 PM, Marcio Galli wrote:
> ob.add("final-ui-startup", cb);
>
> And nothing happens...

Jetpack-based addons used to load early in the startup process. But a
few versions ago we made the loader load them later in the startup
process. I don't know for sure, but I bet they now load after
final-ui-startup, which would explain why your observer no longer
receives notification of that event.

-myk

[Marcio Galli]

Very interesting.  This is cool paragraph ( documentation explanation ) that could go well with the
notion, for developers, that the jetpack addon is executed once ( is once right? like a singleton ) and stays alive sort of thing. This is big change to traditional XUL-chrome extensions where developers used to attach things in the main window.

The case Fabricio had ( another thread about StyleSheet FX4 etc ) is that sort of scenario. In the old extension world, he would need to simply overlay the main browser, while with the new Jetpack architecture he needs to iterate with all windows using the windows mediator.

Is this correct assumption and way to explain ? That Jetpacks, even running in final-ui-startup would be then a one instance app that happens after the very first window is created, then perhaps would I be able to get a reference to a new window if I keep monitoring the final-ui-startup ? ( CTRL N )

m

--
blog.taboca.com

[Myk Melez]

On 2010-08-12 12:46 PM, Marcio Galli wrote:
> Very interesting. This is cool paragraph ( documentation explanation
> ) that could go well with the
> notion, for developers, that the jetpack addon is executed once ( is
> once right? like a singleton ) and stays alive sort of thing. This is
> big change to traditional XUL-chrome extensions where developers used
> to attach things in the main window.

Yes, that's right, the main addon code is executed only once and stays
alive for the life of the application process (or until it gets
uninstalled).

> The case Fabricio had ( another thread about StyleSheet FX4 etc ) is
> that sort of scenario. In the old extension world, he would need to
> simply overlay the main browser, while with the new Jetpack
> architecture he needs to iterate with all windows using the windows
> mediator.

Yes, that's right, although our goal is to provide simple, easy-to-use
APIs for common tasks for which addons used to use XUL overlays, like
adding icons to the browser chrome.

> Is this correct assumption and way to explain ? That Jetpacks, even
> running in final-ui-startup would be then a one instance app that
> happens after the very first window is created, then perhaps would I
> be able to get a reference to a new window if I keep monitoring the
> final-ui-startup ? ( CTRL N )

I think final-ui-startup only fires once, but if you wanted to find out
each time a new window opened, you could do so by using the window-utils
module, which lets you register as a listener for window open events. As
I understand it, it'll even notify you about windows that have already
been opened upon registration, so you don't have to have different code
paths for already opened windows and those that will open in the future.

-myk