Do Firefox extensions work in Camino?
Moderator: Camino Developers
-
- Posts: 55
- Joined: October 4th, 2004, 6:10 am
Do Firefox extensions work in Camino?
help!
Last edited by poorsinfa on August 18th, 2006, 7:45 am, edited 1 time in total.
-
- Camino Developer
- Posts: 2430
- Joined: March 16th, 2004, 1:50 pm
Making Firefox extensions work in Camino is impossible (with a very, very few exceptions) because the front end for the two browsers is completely different (Firefox and Mozilla use XUL, where the entire browser is pretty much a web page, wherease Camino uses Cocoa, which is OS X native), and Firefox extensions depend on that.
Making Camino extensible should be theoritically possible, but it would have to be done pretty much for scratch and would be a *lot* of work.
Making Camino extensible should be theoritically possible, but it would have to be done pretty much for scratch and would be a *lot* of work.
- Uncle Asad
- Camino Developer
- Posts: 3957
- Joined: July 24th, 2004, 1:38 pm
- Location: بين العالمين
- Contact:
There is an enhancement bug filed asking for support for some extensions which don't depend on XUL, which may or may not be relevant to the extensions in which you're interested.
Mac OS X 10.3.9 • PowerBook G4 17" 1.33 GHz | Mac OS X 10.5.x • MacBook Pro 15" 2.2 GHz
Snow7's Camino Forum FAQ Search the Forum Camino. Help Troubleshoot Camino
Snow7's Camino Forum FAQ Search the Forum Camino. Help Troubleshoot Camino
- jonhicks
- Posts: 686
- Joined: January 27th, 2003, 4:07 pm
- Location: Oxfordshire. UK
- Contact:
-
- Posts: 67
- Joined: December 11th, 2003, 8:45 pm
- Location: NC
- Uncle Asad
- Camino Developer
- Posts: 3957
- Joined: July 24th, 2004, 1:38 pm
- Location: بين العالمين
- Contact:
From my understanding, Cocoa (UI) and XUL are completely antithetical. One can't combine them; one can't interchange them.
One can't make Firefox have a Cocoa UI; try to retrofit a Cocoa UI on to the backend and one ends up (essentially) with Camino.
At least that's what I understand. I hope that the new Camino website team goes in to a little more detail than the current buzz-phrase "Camino™ is a web browser optimized for Mac OS X with a Cocoa user interface, and powerful Gecko layout engine" and explains what this means to the end-user and the benefits. Besides being native and using .nibs and aqua form widgets (rather than a bunch of JS and CSS), what does a Cocoa UI really mean? I don't know. I do know those reasons are good enough for me to choose Camino over Firefox (among other reasons, but looks do count), but I am interested in learning more and better understanding things
One can't make Firefox have a Cocoa UI; try to retrofit a Cocoa UI on to the backend and one ends up (essentially) with Camino.
At least that's what I understand. I hope that the new Camino website team goes in to a little more detail than the current buzz-phrase "Camino™ is a web browser optimized for Mac OS X with a Cocoa user interface, and powerful Gecko layout engine" and explains what this means to the end-user and the benefits. Besides being native and using .nibs and aqua form widgets (rather than a bunch of JS and CSS), what does a Cocoa UI really mean? I don't know. I do know those reasons are good enough for me to choose Camino over Firefox (among other reasons, but looks do count), but I am interested in learning more and better understanding things
-
- Posts: 234
- Joined: February 11th, 2003, 8:09 pm
I'm wondering if extension support *might* become more feasible after the 10.4 release. If I understand correctly, Tiger's Dashboard gadgets/widgets/whatever are also "essentially web pages," perhaps the same way that XUL apps like Firefox are. Like many others here, I look in awe upon those who have mastered the black art of coding, but haven't been able to study the art myself. In any event, am I barking up a completely strange tree here, or would Tiger support for these thingies help the Camino extension issue?
-
- Posts: 3
- Joined: October 30th, 2004, 11:04 am
Yes, it may be possible to use the Dashboard infrastructure in this way. Hyatt said, in part:
"A Dashboard widget is a bundle that contains a principal HTML file and any supporting code that the widget requires (be it CSS, JS, images, or native code). A widget can add an optional interface to native code, written in Objective-C, that can be bound into JavaScript and made accessible from the HTML document's JS window object...the "native code as a service accessible from JS" model should be familiar to anyone who has used XPCOM with XUL. It's essentially the same idea. Extensions to the Firefox browser that contain native code can expose that native code to script as an XPCOM service, and then that object can be obtained from JS and have methods/properties invoked."
However, I think some important client-side technology to do "extensions" will reside in Mac OS X 10.4 webcore and specialized Safari html tags, neither of which Camino uses. Actually, Camino could gain the ability to use the Apple extentions and webcore functions, since they are open, but this path would truly make Camino a two-headed monster, sort of a "Safino" or "Camari." It's not on the Camino radar screen.
So Camino is stuck between not using XUL (needed for the vast majority of Firefox extensions) and not using Apple HTML extensions (needed for Dashboard-style "extensions"). Maybe Stuart M. can enlighten, if he's allowed
"A Dashboard widget is a bundle that contains a principal HTML file and any supporting code that the widget requires (be it CSS, JS, images, or native code). A widget can add an optional interface to native code, written in Objective-C, that can be bound into JavaScript and made accessible from the HTML document's JS window object...the "native code as a service accessible from JS" model should be familiar to anyone who has used XPCOM with XUL. It's essentially the same idea. Extensions to the Firefox browser that contain native code can expose that native code to script as an XPCOM service, and then that object can be obtained from JS and have methods/properties invoked."
However, I think some important client-side technology to do "extensions" will reside in Mac OS X 10.4 webcore and specialized Safari html tags, neither of which Camino uses. Actually, Camino could gain the ability to use the Apple extentions and webcore functions, since they are open, but this path would truly make Camino a two-headed monster, sort of a "Safino" or "Camari." It's not on the Camino radar screen.
So Camino is stuck between not using XUL (needed for the vast majority of Firefox extensions) and not using Apple HTML extensions (needed for Dashboard-style "extensions"). Maybe Stuart M. can enlighten, if he's allowed
-
- Camino Developer
- Posts: 2430
- Joined: March 16th, 2004, 1:50 pm
Before asking whether or not it's possible, a good question to ask might be: given that Camino specifically chose *not* to go the route of building a web interface on top of native system calls when a technology to do so (XUL) was already available, is a new application that builds interfaces out of HTML likely to change anything for Camino?
-
- Posts: 3
- Joined: October 30th, 2004, 11:04 am
No, it is very unlikely that Camino will use any kind of web-app plugin, unless it's standardized and comes with Gecko for free. Perhaps a couple of the new Apple html additions, like canvas, may make it into WHATWG, get picked up by Gecko and trickle down to Camino, but I'm not expecting anything drastic.
I see Safari and Firefox becoming more feature-competitive, but Camino was intended to be lightweight, so it should emphasize speed, ease-of-use, simplicity.
I see Safari and Firefox becoming more feature-competitive, but Camino was intended to be lightweight, so it should emphasize speed, ease-of-use, simplicity.
-
- Posts: 99
- Joined: January 15th, 2004, 4:51 pm
- Location: Portland, OR
<b><i>Camino was intended to be lightweight, so it should emphasize speed, ease-of-use, simplicity.</i></b><br><br>I agree. Except for one thing. Adblock. Adblock. Adblock. We desperately need ad blocking functionality in Camino. Firefox has Adblock, Safari has PithHelmet.<br><br>No debates about the merits of blocking ads please. The main reason is the ability to block Flash based ads - while still keeping legitimate Flash viewable... (In my opinion). But also, when I am browsing on dial-up or over cell phone, I like to disable ads for bandwith usage reduction. On broadband, they can stay on - except for the Flash based ads. Flash based ads = evil incarnate.