On Dec 21, 10:39 pm, "John J. Barton" <johnjbar...@johnjbarton.com> wrote:
> What is the difference between -chrome and -app? -chrome opens a chrome > URL, its not firefox, it looks like a different app. So whats -app do?
> jjb
-app will launch a completely new application, a xulrunner-based application. But instead of using a xulrunner runtime, the Firefox libxul runtime is used. The application is _not_ launched into a Firefox process. The only thing I can think of that is different than using xulrunner itself, is the extra Firefox browser components _are_ loaded with the application.
Mark Finkle wrote: > On Dec 21, 10:39 pm, "John J. Barton" <johnjbar...@johnjbarton.com> > wrote: >> What is the difference between -chrome and -app? -chrome opens a chrome >> URL, its not firefox, it looks like a different app. So whats -app do?
>> jjb
> -app will launch a completely new application, a xulrunner-based > application. But instead of using a xulrunner runtime, the Firefox > libxul runtime is used. The application is _not_ launched into a > Firefox process. The only thing I can think of that is different than > using xulrunner itself, is the extra Firefox browser components _are_ > loaded with the application.
Thanks, so -app is Firefox libxul runtime + Firefox browser components. As in xpcom components?
Is Firefox libxul runtime used in Firefox ? If yes then what is missing in: Firefox = Firefox libxul runtime + browser components + ?
Mark Finkle wrote: > On Dec 22, 12:45 am, "John J. Barton" <johnjbar...@johnjbarton.com> > wrote: >> Is Firefox libxul runtime used in Firefox ? If yes then what is missing in: >> Firefox = Firefox libxul runtime + browser components + ?
> The Firefox front-end GUI itself
> Also, when launched using -app, an application uses it own profile > folder, not the Firefox profile.
So....if I ran Firefox process with -chrome <myurl> but did not open Firefox, then called the same code as -app <app.ini> calls then....?
I guess the -app code can't find the app because of the profile. But I suppose that could be fixed up with some reg directory work.
(I'm trying to guess how much work would be needed to apply chromebug to songbird). jjb
Mark Finkle wrote: > On Dec 21, 10:39 pm, "John J. Barton"<johnjbar...@johnjbarton.com> > wrote: >> What is the difference between -chrome and -app? -chrome opens a chrome >> URL, its not firefox, it looks like a different app. So whats -app do?
>> jjb
> -app will launch a completely new application, a xulrunner-based > application. But instead of using a xulrunner runtime, the Firefox > libxul runtime is used. The application is _not_ launched into a > Firefox process. The only thing I can think of that is different than > using xulrunner itself, is the extra Firefox browser components _are_ > loaded with the application.
-app is basically Firefox pretending to be XULRunner (I almost said "misusing Firefox as XULRunner"), and this option is special to Firefox, no other XUL app that I know of has this support. -chrome on the other hand is supported by any XUL app (even 1.x suite) and just opens a window with that chrome in the environment of that app.
Robert Kaiser wrote: > -chrome on the other hand is supported by any XUL app (even 1.x suite) > and just opens a window with that chrome in the environment of that app.
So if I put Chromebug down in a thunderbird profile and ran thunderbird with -chrome <chrombug URI>, it might work. For FF I start FF with "window.open(URL)"; how could I open thunderbird or another app instead?
> So if I put Chromebug down in a thunderbird profile and ran thunderbird > with -chrome <chrombug URI>, it might work. For FF I start FF with > "window.open(URL)"; how could I open thunderbird or another app instead?
Why is chromebug using -chrome? It seems more useful for me for chromebug to implement its own command-line handler, so that you could do, e.g.
firefox -chromebug
And it would launch chromebug and then launch the browser normally.
The key here is, I think, to avoid setting cmdLine.preventDefault = true. This means that after you open the chromebug window, startup will continue on normally.
Benjamin Smedberg wrote: > On 12/22/08 12:22 PM, John J. Barton wrote: >> Robert Kaiser wrote:
>>> -chrome on the other hand is supported by any XUL app (even 1.x suite) >>> and just opens a window with that chrome in the environment of that app.
> This is incorrect.
Thanks for clearing this up, I didn't know about that.
>> So if I put Chromebug down in a thunderbird profile and ran thunderbird >> with -chrome <chrombug URI>, it might work. For FF I start FF with >> "window.open(URL)"; how could I open thunderbird or another app instead?
> Why is chromebug using -chrome? It seems more useful for me for chromebug to > implement its own command-line handler, so that you could do, e.g.
> firefox -chromebug
> And it would launch chromebug and then launch the browser normally.
> The key here is, I think, to avoid setting cmdLine.preventDefault = true. > This means that after you open the chromebug window, startup will continue > on normally.
Ok thanks I can do that and simplifying the startup is good. But what I was really after here was a way to try with thunderbird and songbird.
> Benjamin Smedberg wrote: >> Why is chromebug using -chrome? It seems more useful for me for >> chromebug to >> implement its own command-line handler, so that you could do, e.g.
>> firefox -chromebug
>> And it would launch chromebug and then launch the browser normally.
>> The key here is, I think, to avoid setting cmdLine.preventDefault = true. >> This means that after you open the chromebug window, startup will >> continue >> on normally.
> Ok thanks I can do that and simplifying the startup is good. But what I > was really after here was a way to try with thunderbird and songbird.
Thunderbird (and I believe Songbird) should support the same command line handler interfaces. Therefore you can use exactly the same code to let you do
> Thunderbird (and I believe Songbird) should support the same command > line handler interfaces. Therefore you can use exactly the same code to > let you do
> thunderbird -chromebug > songbird -chromebug.
> Standard8.
Well its a nice theory anyway ;-)
I ran into three problems: 1) The install.rdf for has to have a stanza for thunderbird, songbird, whatever. It does not seem possible to have a mozilla platform tool using this technology. To use chromebug on a new app you have to edit all of its install.rdf files and add your app to it. 2) Unlike FF, thunderbird does not notice changes to the extensions folder. I had to delete extensions.* to get the extensions to be loaded. 3) chromebug fails to load because of xul errors.
I guess I could look at the other half of the glass: by editing the install.rdf files, installing chromebug extensions in to thunderbird, deleting extensions.*, and running thunderbird with -chromebug it looks possible to apply chromebug to a XUL app other than Firefox.
> Mark Banner wrote: > ... >> Thunderbird (and I believe Songbird) should support the same command >> line handler interfaces. Therefore you can use exactly the same code >> to let you do
>> thunderbird -chromebug >> songbird -chromebug.
>> Standard8.
> Well its a nice theory anyway ;-)
> I ran into three problems: > 1) The install.rdf for has to have a stanza for thunderbird, > songbird, whatever. It does not seem possible to have a mozilla > platform tool using this technology. To use chromebug on a new app you > have to edit all of its install.rdf files and add your app to it.
> 2) Unlike FF, thunderbird does not notice changes to the extensions > folder. I had to delete extensions.* to get the extensions to be loaded.
This works for me with other extensions... if you install or update the extension I suspect it will work for you as well. I've had problems in the past where modifying files in place (especially the install.rdf) wouldn't get picked up.
> 3) chromebug fails to load because of xul errors.
This is often caused by relying on app provided locale strings.
> On 12/23/2008 9:46 AM, John J. Barton wrote: >> Mark Banner wrote: >> ... >>> Thunderbird (and I believe Songbird) should support the same command >>> line handler interfaces. Therefore you can use exactly the same code >>> to let you do
>> I ran into three problems: >> 1) The install.rdf for has to have a stanza for thunderbird, >> songbird, whatever. It does not seem possible to have a mozilla >> platform tool using this technology. To use chromebug on a new app you >> have to edit all of its install.rdf files and add your app to it. > You can use tool...@mozilla.org as the targetApplication ID and Toolkit > version (Toolkit version maps to Gecko version) to specify compatibility > with a Toolkit. > https://developer.mozilla.org/en/Extension_Versioning,_Update_and_Com...
Though it's not really all that useful if you want your addon to be usefully represented on addons.mozilla.org -- you'll have to go through and do the install.rdf hacking anyway for every toolkit app you care about (and figuring out the right versions of that app that correspond to the toolkit versions you're compatible with).
> Though it's not really all that useful if you want your addon to be > usefully represented on addons.mozilla.org -- you'll have to go > through and do the install.rdf hacking anyway for every toolkit app > you care about (and figuring out the right versions of that app that > correspond to the toolkit versions you're compatible with).
John J. Barton wrote: > Well its a nice theory anyway ;-)
> I ran into three problems: > 1) The install.rdf for has to have a stanza for thunderbird, songbird, > whatever. [...] you have to edit > all of its install.rdf files and add your app to it. ... > 3) chromebug fails to load because of xul errors.
Number 3 explains 1, right? Many addons "should" work for any XUL-based app, and yet in practice they don't without mods/special-casing. There's no way for the engine to know without the developer saying in some explicit way "my addon is compatible with this app and not that one".
Daniel Veditz wrote: > John J. Barton wrote: >> Well its a nice theory anyway ;-)
>> I ran into three problems: >> 1) The install.rdf for has to have a stanza for thunderbird, songbird, >> whatever. [...] you have to edit >> all of its install.rdf files and add your app to it. > ... >> 3) chromebug fails to load because of xul errors.
> Number 3 explains 1, right? Many addons "should" work for any XUL-based > app, and yet in practice they don't without mods/special-casing. There's > no way for the engine to know without the developer saying in some > explicit way "my addon is compatible with this app and not that one".
No, #1 means you can't even load so you never get to #3. Surely there is some code in chromebug specific to firefox, eg the locale strings suggested by Robert Strong. I'm encourage to believe that the obstacles could be over come with modest motivation.
> Daniel Veditz wrote: > > John J. Barton wrote: > >> Well its a nice theory anyway ;-)
> >> I ran into three problems: > >> 1) The install.rdf for has to have a stanza for thunderbird, songbird, > >> whatever. [...] you have to edit > >> all of its install.rdf files and add your app to it. > > ... > >> 3) chromebug fails to load because of xul errors.
> > Number 3 explains 1, right? Many addons "should" work for any XUL-based > > app, and yet in practice they don't without mods/special-casing. There's > > no way for the engine to know without the developer saying in some > > explicit way "my addon is compatible with this app and not that one".
> No, #1 means you can't even load so you never get to #3. Surely there is > some code in chromebug specific to firefox, eg the locale strings > suggested by Robert Strong. I'm encourage to believe that the obstacles > could be over come with modest motivation.
> jjb
Using tool...@mozilla.org, as suggested by Robert Strong, will allow any xulrunner based app to load your extension as long as you use a commandline handler, as suggested by Benjamin, and use no overlays into the xul application. You could use overlays only if you make them explicit per application in your chrome manifest using the "application" manifest flag.
The latest DOMi and Venkman use tool...@mozilla.org and I am able to load both into my xul-based apps from the commandline - including Fennec on an n810.
Mark Finkle wrote: > On Dec 24, 1:17 am, "John J. Barton" <johnjbar...@johnjbarton.com> > wrote: >> Daniel Veditz wrote: >>> John J. Barton wrote: >>>> Well its a nice theory anyway ;-) >>>> I ran into three problems: >>>> 1) The install.rdf for has to have a stanza for thunderbird, songbird, >>>> whatever. [...] you have to edit >>>> all of its install.rdf files and add your app to it. >>> ... >>>> 3) chromebug fails to load because of xul errors. >>> Number 3 explains 1, right? Many addons "should" work for any XUL-based >>> app, and yet in practice they don't without mods/special-casing. There's >>> no way for the engine to know without the developer saying in some >>> explicit way "my addon is compatible with this app and not that one". >> No, #1 means you can't even load so you never get to #3. Surely there is >> some code in chromebug specific to firefox, eg the locale strings >> suggested by Robert Strong. I'm encourage to believe that the obstacles >> could be over come with modest motivation.
>> jjb
> Using tool...@mozilla.org, as suggested by Robert Strong, will allow > any xulrunner based app to load your extension as long as you use a > commandline handler, as suggested by Benjamin, and use no overlays > into the xul application. You could use overlays only if you make them > explicit per application in your chrome manifest using the > "application" manifest flag.
Sorry I guess I left one sentence out. Once I fixed the install.rdf I still have a problem, so #3 does not explain #1.
I changed the install.rdf to use tool...@mozilla.org; I changed the command line handler to use -chromebug. This works on FF3.0, crashes on FF3.1b2, and has some XUL problem on thunderbird. It's a work in progress...
Robert Strong wrote: > On 12/23/2008 9:46 AM, John J. Barton wrote: ... >> 3) chromebug fails to load because of xul errors. > This is often caused by relying on app provided locale strings.
So...is there something like chrome://toolkit/locale/toolkit.dtd, for platform bindings of things like undo, cut, paste, ...?
Shawn Wilsher wrote: > On 12/26/08 10:32 AM, John J. Barton wrote: >> So...is there something like chrome://toolkit/locale/toolkit.dtd, >> for platform bindings of things like undo, cut, paste, ...? > There are all sorts of strings available: > http://mxr.mozilla.org/mozilla-central/source/toolkit/locales/en-US/c...
Thanks! chrome://global/locale/editMenuOverlay.dtd did most of the work.
Yes, actually we already had the work around in for FF2. The error message was not stopping progress. Instead, it looks like Thunderbird is not registering my command line handler. I deleted compreg.dat and checked it: firebug components are registered but not chromebug command line handler (which works in Firefox). Further evidence is a message in the OS console: Warning: unrecognized command line flag -chromebug
On Mon, 29 Dec 2008 18:36:52 -0800, John J. Barton wrote: > Shawn Wilsher wrote: >> On 12/26/08 11:32 AM, John J. Barton wrote: >>> thunderbird says Unrecognized chrome registration modifier >>> 'contentaccessible=yes' >> I'm assuming Thunderbird 2? The devmo wiki page on contentaccessible
> Yes, actually we already had the work around in for FF2. The error > message was not stopping progress. Instead, it looks like Thunderbird is > not registering my command line handler. I deleted compreg.dat and > checked it: firebug components are registered but not chromebug command > line handler (which works in Firefox). Further evidence is a message in > the OS console: > Warning: unrecognized command line flag -chromebug
> More hints?
Here's one: The DOM Inspector command line handler component works in: SeaMonkey 1.1 (a XPFE, non-toolkit application), SeaMonkey 2.0a+, Firefox 2/3.0/3.1, Thunderbird 2/3.0a+ and any toolkit 1.9.0/1.9.1 application.
That may be a bit of overkill. For a simpler cross application implementation you could have a look at some of our code in:
-- Philip Chee <phi...@aleytys.pc.my>, <philip.c...@gmail.com> http://flashblock.mozdev.org/http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. [ ]Do not expose this tagline to direct sunlight. * TagZilla 0.066.6
