Re: Reusing a Firefox extension as a XULRunner app
Benjamin Smedberg
followup to mozilla.dev.extensions
> However, I can't seem to make it work this way, no matter what I try
> and I'm coming to the conclusion that perhaps it can't be done. The
> two main issues I'm facing is that the extension UI is not overlayed
> in the shell UI and that many things the extension code expects (like
> gBrowser/getBrowser for instance) are not readily available. I think I
> could solve the latter, but I'm baffled by the former. I've checked
> every application mentioned in the XULRunner Hall Of Fame that was
> distributed as both an extension and a standalone app and nobody is
> reusing the extension in the way I was expecting.
"extension UI is not overlayed in the shell UI". What do you mean, exactly?
The typical extension which can also be a XULRunner application has its own
window and only uses XUL overlays to provide extension points into the
browser such as toolbar items or menu entries. To make this kind of
extension a standalone app you just open the extension window by itself
(using toolkit.defaultChromeURI or a custom command-line handler) and ignore
the browser overlays which are unneeded.
Certainly browser-specific items such as gBrowser aren't going to be
available, since there is no browser to make gBrowser!
> Now, before I give up and go this route myself and suffer the
> maintenance nightmare that it may entail, I thought I'd ask here if
> perhaps there *are* people out there doing this and I could be pointed
> in the right direction.
I know that chatzilla is used as both very simply.
--BDS
John J. Barton
Chromebug re-uses Firebug code in a xul app. It has more XUL to add UI
and it has some monkey patching.
jjb
Panagiotis Astithas
> On 11/20/09 5:53 AM, Panagiotis Astithas wrote:
>
> followup to mozilla.dev.extensions
Sure, sorry if I picked the wrong venue.
> > However, I can't seem to make it work this way, no matter what I try
> > and I'm coming to the conclusion that perhaps it can't be done. The
> > two main issues I'm facing is that the extension UI is not overlayed
> > in the shell UI and that many things the extension code expects (like
> > gBrowser/getBrowser for instance) are not readily available. I think I
> > could solve the latter, but I'm baffled by the former. I've checked
> > every application mentioned in the XULRunner Hall Of Fame that was
> > distributed as both an extension and a standalone app and nobody is
> > reusing the extension in the way I was expecting.
>
> "extension UI is not overlayed in the shell UI". What do you mean, exactly?
> The typical extension which can also be a XULRunner application has its own
> window and only uses XUL overlays to provide extension points into the
> browser such as toolbar items or menu entries. To make this kind of
> extension a standalone app you just open the extension window by itself
> (using toolkit.defaultChromeURI or a custom command-line handler) and ignore
> the browser overlays which are unneeded.
>
> Certainly browser-specific items such as gBrowser aren't going to be
> available, since there is no browser to make gBrowser!
This typical extension-to-standalone-application scenario that you
describe is what I see everyone else is doing, too. It's just that you
hit some snags here and there, like the fact that I can't use the same
code to open a new tab in the standalone version of my extension,
since there is no browser, as you say. I expect these issues to force
me into keeping two versions of the same files in some cases,
differing only in a few small parts (the maintenance nightmare I was
referring to).
So, the idea I was trying to pursue is to have my standalone app be a
XUL window containing a tabbrowser or a browser element, and a
statusbar element, since that is what my extension requires from it's
host environment, with the same ids as in Firefox. I've also supplied
the gBrowser/getBrowser globals that would be returning the tabbrowser/
browser above, in order to make the extension believe it's hosted in
Firefox. Then I change the extension's manifests to add installation
hooks for the standalone app and indeed, it is installed fine. The
problem is that the hooks in the overlay XUL file do not seem to lead
to a visual merge in the window, leaving it empty. I've tried both top-
down (xul-overlay) and bottom-up (matching ids in the overlay.xul)
approaches to no avail.
If I could make this approach work, I would be distributing to my
users a small XULRunner app with just the hosting environment, and it
would be reusing the extension XPI that I'm currently distributing to
Firefox users. The core domain-specific code which would reside in the
extension would be automatically updated when I release new versions,
through the extension manager, with no further work on my part!
> > Now, before I give up and go this route myself and suffer the
> > maintenance nightmare that it may entail, I thought I'd ask here if
> > perhaps there *are* people out there doing this and I could be pointed
> > in the right direction.
>
> I know that chatzilla is used as both very simply.
It was when I saw that even chatzilla uses the different-packages
approach that I decided to post this message :-)
I don't know how chatzilla does it, but when I tried this traditional
route, I used build script magic to package the code differently in
the extension and application packages. If I should just give in and
go down that route, is there a smarter way of doing it?
Thanks,
--
Panagiotis Astithas
http://www.linkedin.com/in/astithas
Panagiotis Astithas
wrote:
Is there a standalone version of chromebug that does this? In my local
copy of the chromebug extension I think I can spot the Firebug code in
the fb4cb directory. This is similar to what I was doing initially
(the traditional approach I describe in my other post), with the only
difference being that I packaged the original extension code as
separate jar files in my XULRunner app. However, I'd like to go to a
full-reuse scenario (like I said in my other post), where the
XULRunner code would just host the original extension XPI and thing
would Just Work (TM).
Gijs Kruitbosch
>>> Now, before I give up and go this route myself and suffer the
>>> maintenance nightmare that it may entail, I thought I'd ask here if
>>> perhaps there *are* people out there doing this and I could be pointed
>>> in the right direction.
>>
>> I know that chatzilla is used as both very simply.
>
> It was when I saw that even chatzilla uses the different-packages
> approach that I decided to post this message :-)
> I don't know how chatzilla does it, but when I tried this traditional
> route, I used build script magic to package the code differently in
> the extension and application packages. If I should just give in and
> go down that route, is there a smarter way of doing it?
>
> Thanks,
> --
> Panagiotis Astithas
> http://www.linkedin.com/in/astithas
I'm not sure what you mean by "different packages". Do you mean that there are
different zip files available for the XUL app and the add-on? That is just
because the XUL app needs an application.ini file and some extra preferences (as
Benjamin mentioned) to indicate which XUL file to load as the main window. All
the other code basically remains identical (although the packages Rob Marshall
makes available have integration with eg. about:config, for which we do need
some extra code).
I'm not sure what your add-on is trying to do, but it really sounds like it
needs a browser to be useful/functional. ChatZilla doesn't. It just needs Necko
networking components and so on, so it doesn't create a XUL window with a fake
gBrowser or anything like that. If your add-on does require a browser window,
then could I ask, why exactly are you turning it into a xulrunner app? What does
it do that it does better by re-doing the browser part itself?
The problem with "emulating" Firefox with a small faked window etc. is that the
UI that the user is used to doesn't exist, they have no control over some of the
features that are actually available in XULRunner that have no UI anymore (eg.
password/login manager, cookies, etc.) -- and so I am struggling to understand
what your add-on does that makes it (a) require a browser in XULRunner and (b)
work better as a standalone XUL app than a browser add-on.
Gijs
Panagiotis Astithas
> On 21/11/2009 10:34 AM, Panagiotis Astithas wrote:
> >>> Now, before I give up and go this route myself and suffer the
> >>> maintenance nightmare that it may entail, I thought I'd ask here if
> >>> perhaps there *are* people out there doing this and I could be pointed
> >>> in the right direction.
>
> >> I know that chatzilla is used as both very simply.
>
> > It was when I saw that even chatzilla uses the different-packages
> > approach that I decided to post this message :-)
> > I don't know how chatzilla does it, but when I tried this traditional
> > route, I used build script magic to package the code differently in
> > the extension and application packages. If I should just give in and
> > go down that route, is there a smarter way of doing it?
>
> > Thanks,
> > --
> > Panagiotis Astithas
> >http://www.linkedin.com/in/astithas
>
> I'm not sure what you mean by "different packages". Do you mean that there are
> different zip files available for the XUL app and the add-on? That is just
> because the XUL app needs an application.ini file and some extra preferences (as
> Benjamin mentioned) to indicate which XUL file to load as the main window. All
> the other code basically remains identical (although the packages Rob Marshall
> makes available have integration with eg. about:config, for which we do need
> some extra code).
Yes, I was referring to the fact that, chatzilla for instance, cannot
currently reuse the xpi hosted in AMO, from the chatzilla-xx-xr.zip
package. The benefits from being able to do that, are:
- you could keep the core chatzilla functionality in the chatzilla.xpi
and simply put the xulrunner "application shell" in the chatzilla-
xr.zip that would only change if/when you want to support newer
xulrunner versions/APIs
- you could keep users of the xulrunner version updated from the same
extension manager mechanism, as users of the firefox add-on
- you don't need any fancy build process to produce the two artifacts
(chatzilla.xpi & chatzilla-xr.zip), since they do not share any code
at all
Essentially what I'm trying to do is find a way to conform to the old
OOP adage of encapsulation and reusability.
> I'm not sure what your add-on is trying to do, but it really sounds like it
> needs a browser to be useful/functional. ChatZilla doesn't. It just needs Necko
> networking components and so on, so it doesn't create a XUL window with a fake
> gBrowser or anything like that. If your add-on does require a browser window,
> then could I ask, why exactly are you turning it into a xulrunner app? What does
> it do that it does better by re-doing the browser part itself?
>
> The problem with "emulating" Firefox with a small faked window etc. is that the
> UI that the user is used to doesn't exist, they have no control over some of the
> features that are actually available in XULRunner that have no UI anymore (eg.
> password/login manager, cookies, etc.) -- and so I am struggling to understand
> what your add-on does that makes it (a) require a browser in XULRunner and (b)
> work better as a standalone XUL app than a browser add-on.
That's a fair point, allow me to clarify.
FireGSS (http://code.google.com/p/firegss/), the extension we are
developing is a FireFTP-derivative that presents a file manager
interface to a cloud-based storage service we have built, GSS (http://
code.google.com/p/gss/). The service presents a REST-like API to
clients and besides the default web UI, we'd like to provide users
with a more traditional desktop application option, in order to allow
multiple file uploads & downloads, drag & drop, directory sync, etc.
This is why we came up with the firefox extension. The only thing in
there that requires a browser, is the authentication mechanism that
uses Shibboleth (http://shibboleth.internet2.edu/), which is web-only.
So, the extension opens a new tab each time the user needs to log in
to the service, and after the authentication process is done, the tab
is automatically closed and the user returns to the application
window. Now, I could certainly do this from a xulrunner app by opening
another XUL window that contains a browser element, but I'm trying to
reuse the extension's code that deals with tabs, so that I won't have
to maintain two different code bases for the authentication process.
So, I'm not trying to make the user believe that the xulrunner app is
Firefox in disguise, I'm trying to make the FireGSS extension believe
it. As far as the user is concerned, the standalone version has
nothing to do with Firefox. We are actually developing it to cater to
the needs of people who don't like or use Firefox in general, or
Firefox extensions in particular. It's just a separate distribution
venue for the file manager code originally packaged in a Firefox
extension.
I hope this clears it up a bit.
John J. Barton
> On Nov 21, 5:23 am, "John J. Barton" <johnjbar...@johnjbarton.com>
> wrote:
>> Benjamin Smedberg wrote:
>>> On 11/20/09 5:53 AM, Panagiotis Astithas wrote:
>>>> Now, before I give up and go this route myself and suffer the
>>>> maintenance nightmare that it may entail, I thought I'd ask here if
>>>> perhaps there *are* people out there doing this and I could be pointed
>>>> in the right direction.
>>> I know that chatzilla is used as both very simply.
>> Chromebug re-uses Firebug code in a xul app. It has more XUL to add UI
>> and it has some monkey patching.
>
> Is there a standalone version of chromebug that does this? In my local
No, I always run it using the xul container called Firefox.
> copy of the chromebug extension I think I can spot the Firebug code in
> the fb4cb directory. This is similar to what I was doing initially
Yes fb4cb is an svn:external link to the Firebug svn tree.
> (the traditional approach I describe in my other post), with the only
> difference being that I packaged the original extension code as
> separate jar files in my XULRunner app. However, I'd like to go to a
> full-reuse scenario (like I said in my other post), where the
> XULRunner code would just host the original extension XPI and thing
> would Just Work (TM).
Of course the XULRunner code that will work for sure is Firefox ;-).
jjb