Bug#440938: ITP: xulrunner-l10n -- language packages for xulrunner
On Wed, Sep 05, 2007 at 06:45:18PM +0200, arno <arenevier@fdn.fr> wrote:
> Le mercredi 05 septembre 2007, à 17:50:35 +0200, Mike a écrit :
> >
> > Actually, it *does* allow global extensions, but applications embedding
> > libxul or using xulrunner have to initialize the extensions manager by
> > themselves in order to get these extensions enabled. This is something that
> > is, unfortunately, not very likely to change.
>
> What I meant here is you can use global extension for some applications, but not
> for xulrunner globally. ie: an extension has to provide an install.rdf
> referencing all xulrunner application it works with.
>
> So if you have a xulrunner extension, and you create a new application, you
> must:
> - enable extension manager (easy: can be done in the application itself)
> - change something in extension install.rdf (difficult: you must modify another
> debian package). That's what I want to avoid here.
>
> I think it will be easier to avoid that in xulrunner 1.9 (I'm not totally sure,
> but that's what I understand from mozilla bug 299716)
Yes, in this case, the changes scheduled for xulrunner 1.9 might be
helpful.
> > Note having added stuff in the chrome without extensions recently, I can't
> > tell you if it will be necessary to go through a registration phase, but
> > I think putting a chrome.manifest file alongside should be enough.
>
> adding a .jar and a manifest in /usr/share/xulrunner/chrome/ seems to work fine.
> That's the way we do things in my paid job. But if you want to provide
> a components/ directory, you have to provide a real extension - otherwise, the
> component(s) may not be reregistered after modifications.
You can add the component(s) in /usr/lib/xulrunner/components and
touch the /usr/lib/xulrunner/.autoreg file. The new component(s) will be
autoregistered at application startup. (Works the same with removed
components). See the xulrunner-gnome-support package.
Mike
Reply to: