Camino browser reaches its end(caminobrowser.org)
caminobrowser.org
Camino browser reaches its end
http://caminobrowser.org/
126 comments
I loved Camino back in the 10.1 / 10.2 days. It was truly epic , and so much better than the god awful IE for Mac.
I still love it. To this day it remains my primary browser, through its aged rendering, through its lockups on JS-heavy sites, through its dated icons, through everything. Because the UI of every other browser just feels wrong. Aside from Safari maybe, but Safari's tab bar makes it impossible to handle 50+ tabs.
Pick any of the main browsers, the main advance in the UI is the slimming down of controls. Even Opera went from a g'zillion toolbars down to a slim default interface. The rendering engines receive loads of attention while the basic browser UI is just plain boring and out dated. Camino doesn't really look that out of place even today.
Has Firefox gone completely native then on OSX? From what I can tell on Linux is that Firefox and Opera stand out (and even Chrome that shuns your system title bar..) These three apps are out of place on my desktop. At least Camino blended in.
Has Firefox gone completely native then on OSX? From what I can tell on Linux is that Firefox and Opera stand out (and even Chrome that shuns your system title bar..) These three apps are out of place on my desktop. At least Camino blended in.
50+ tabs!!
I know! How does he manage to have so few?
he's one of the people who partly (because he's still over 10 tabs) gets the current bookmark-systems in browsers.
For most users the bookmarks seem to be broken/too complex. Never had the problem, maybe because I'm going crazy when I got over 10 tabs and want to get rid of them ASAP. :\
For most users the bookmarks seem to be broken/too complex. Never had the problem, maybe because I'm going crazy when I got over 10 tabs and want to get rid of them ASAP. :\
Just looking around reddit you easily pass the 50 tabs threshold.
Bookmarks are far from ideal (at least in firefox) and technically you don't need them today since the history works well in case you need to find something (just typing related terms on the address bar) but the history is erased quite often so it's better to have certain urls bookmarked and using the aforementioned address bar to find what you're looking for (or the search on the bookmarks manager). It works for me.
Bookmarks are far from ideal (at least in firefox) and technically you don't need them today since the history works well in case you need to find something (just typing related terms on the address bar) but the history is erased quite often so it's better to have certain urls bookmarked and using the aforementioned address bar to find what you're looking for (or the search on the bookmarks manager). It works for me.
I still bookmark, but only because it helps to make sure those results have a higher priority in the address bar.
I have absolutely no idea what you're talking about. I don't use bookmarks, I used to put things in there and never find them when I needed them, so I've stopped doing that.
I'll actually put things in there when I want to remember them. Firefox makes it a little better because you can attach keywords to them to help you search later.
IE for Mac? That has to be an oxy moron of some sort.
For a surprisingly long window of time, IE Mac was the best browser around. Apparently, it did not share a code base with Windows IE, which explains why IE Mac had all the features people were drooling over in 2001 like full PNG transparency and good CSS support. PNG support even included color correction, and IE Mac did not suffer from the "box model" bug that affected IE on Windows.
I think the Mac version of IE had something like 99% compliance on the first Acid test, before other browsers had robust CSS support. You could even find a copy of the Acid test in an easter egg in the browser.
It was a fantastic browser at the time, but didn't align with Microsoft's future interests and the development team was reassigned.
I think the Mac version of IE had something like 99% compliance on the first Acid test, before other browsers had robust CSS support. You could even find a copy of the Acid test in an easter egg in the browser.
It was a fantastic browser at the time, but didn't align with Microsoft's future interests and the development team was reassigned.
> and IE Mac did not suffer from the "box model" bug that affected IE on Windows.
Nope. Just the box model bug that affected all the CSS 2 compliant browsers. ;)
It was indeed a pretty good browser for its time, though.
Nope. Just the box model bug that affected all the CSS 2 compliant browsers. ;)
It was indeed a pretty good browser for its time, though.
For all the woe brought upon the web by Internet Explorer 6, the "box model bug" is indeed the one thing it did right. It took far too long for everyone else to admit the error and move ahead with the box-sizing CSS spec.
You mean IE5?
In 2001 I, for the first time in my life, had access to Macs running Mac OS 9. While I didn't like the operating system much (I was using Linux and Windows at home, the idea of having to assign memory to application manually felt so 80s) I instantly fell in love with IE for Mac. Back then, in PC land, Netscape Navigator and IE 5.5 were the dominant browser, and IE for Mac supported all these fantastic CSS properties that I knew about, but that I could not use in NN4 or IE5.5. I spend hours buliding pure CSS websites without images, simply utilizing unicode fonts, and CSS properties. Ah, those were the days.
Unfortunately it had the most annoying bug in that it did not reload CSS files. Back in the day, I developed with a text editor on mac PowerBook and after changing one CSS statement, I had to close the browser and restart it.
MacOS had a built-in web server. You could've used that.
Yea, it was one of the first browsers to implement DOCTYPE switching.
Ehh, IE5:Mac may have been better than IE5:Win, and yes, its CSS and PNG support were ahead of its time, but it was still IE5.
IE5:Mac didn't have support for a lot of things IE6 had that we now consider standard, like :hover for links, for..in, Array.prototype.splice, XmlHttpRequest, contentEditable...
IE5:Mac didn't have support for a lot of things IE6 had that we now consider standard, like :hover for links, for..in, Array.prototype.splice, XmlHttpRequest, contentEditable...
It also was the most standards compliant and performant IE of its time, being a totally different code base.
Possibly because they had to please Apple AND Microsoft?
No. It's because MSIE for Windows wouldn't run on MacOS and they couldn't use Wine. (MSFT would never do that.)
Wine wouldn't have worked either since OSX was PowerPC based at the time.
That and the fact that wine only runs on *nix, so it'd require another compatibility layer to provide POSIX and BSD functionality under classic MacOS. OSX didn't even exist at the time IE for Mac was written. They'd also have to come up with a visual theme layer so they could at least pretend it's a Mac program, long before they introduced one in Windows. All of that still wouldn't get them menu bar support, though. In hindsight, I didn't think it through at all when I mentioned wine.
They do have MS-Office ports for Mac, so that product was probably written with much better separation of concerns.
They do have MS-Office ports for Mac, so that product was probably written with much better separation of concerns.
I guess there's no reason for Microsoft to decouple their browser from their OS, I guess....
Eg. transparent PNGs.
There was an IE for UNIX back in the 1990s, which meant Solaris and HP-UX. The last version was IE5.
http://en.wikipedia.org/wiki/Internet_Explorer_for_UNIX
And before that, MicroSoft was best known for its BASIC implementation that wound up on a whole range of eight-bit microcomputers.
https://en.wikipedia.org/wiki/Microsoft_BASIC
The versions for 6502-based micros shared a codebase:
http://www.pagetable.com/?p=46
And, in some versions, they had an easter egg hidden in the constants used to implement SIN:
http://www.pagetable.com/?p=43
http://en.wikipedia.org/wiki/Internet_Explorer_for_UNIX
And before that, MicroSoft was best known for its BASIC implementation that wound up on a whole range of eight-bit microcomputers.
https://en.wikipedia.org/wiki/Microsoft_BASIC
The versions for 6502-based micros shared a codebase:
http://www.pagetable.com/?p=46
And, in some versions, they had an easter egg hidden in the constants used to implement SIN:
http://www.pagetable.com/?p=43
I find this extremely saddening because Camino offered the best native experience for OS X, with all the polish of a well-designed Cocoa app, on top of Gecko.
I'll miss Camino.
I'll miss Camino.
I want to like Firefox, I really do, but the experience on OS X is awful. It doesn't fit well with the aesthetic of a native Mac app, and certainty doesn't' function like one. Multi-gestures in Safari are so much smoother. About a month or so back when the Firefox team was soliciting feedback for something here on HN, one of the designers or developers at Mozilla had screenshots of a version of Firefox that looked really good. I went to go download the latest version and realized that the screenshots most have just been Photoshop comps or something.
I would have to agree with most of what is said here. I prefer Chrome (or even Safari) over Firefox on OS X. Chrome is faster (I need to work on a slow Internet connection many times) while Safari being the bundled browser has few features like Reader etc. which I don't want to use. I still have FF installed for back up purposes but I don't use it unless something is broken on Chrome or Safari (which doesn't happen a lot).
I find it extremely surprising that some sites (ex:Facebook) are (or were a few months back) displayed differently on Windows FF vs OS X FF.
I find it extremely surprising that some sites (ex:Facebook) are (or were a few months back) displayed differently on Windows FF vs OS X FF.
did it look like this [1]? that's the UX nightly available at [2]. it's a new theme they're working on, but it's got a few versions to go before it makes it into stable. i'm loving it, but they're removing/changing a couple of customization features so people are freaking out. we'll see what the final product ends up looking like.
[1] http://i.imgur.com/Gfns2MS.png
[2] http://people.mozilla.org/~jwein/ux-nightly/
[1] http://i.imgur.com/Gfns2MS.png
[2] http://people.mozilla.org/~jwein/ux-nightly/
It's not just the user interface, it's that (for example) they don't QUITE completely ignore mac (emacs) keybindings (e.g. ctrl-a should move to beginning of PARAGRAPH, but either moves to the beginning of the visual line in the textbox, or highlights whatever you've searched for if you're that unlikely). This is far worse behavior, and it's been like this for years!
Yes! Thank you. While I don't think it looks or feels perfect yet, it at least shows that FF is still in the game working on things like this.
That's hardly a good Mac UI. On the Mac:
1. Tab close buttons should be on the left, not the right.
2. They got the tab title right, in the center, but site icon should be right next to the site title, not on the far left.
1. Tab close buttons should be on the left, not the right.
2. They got the tab title right, in the center, but site icon should be right next to the site title, not on the far left.
Be aware that the UX alpha is highly unstable. Many things are not finished and from time to time just appear and vanish out of thin air.
So it can only be used as a direction indicator and as such, I think it looks good.
So it can only be used as a direction indicator and as such, I think it looks good.
Actually this tab style dates back to at least Firefox 3. I didn't check further back. It looks like XUL can't do it the right way, and they don't care enough to do it right.
It seems like sometimes the play with it and go back to the old one (which I actually like...).
BTW, the UX alpha is back to the old style.
BTW, the UX alpha is back to the old style.
I think the reason they have the icon/close button switched is because when you pin a tab it goes on the left side of the screen.
Oh, interesting. That's what Thunderbird looks like now. I was just noticing the other day that Thunderbird got really nice looking suddenly...
That rounded tab just looks off to me. Everything else looks great though.
The one thing that drives me mad about Firefox on the Mac is it's Home/End behavior. Ever since migrating to the Mac, I have remapped the keys to work like on windows and Linux (operating on the current line instead of the current document).
You can do that using a custom key binding in ~/Library/KeyBindings.
Firefox ignores this and still insists on home/end working on the full document. But even worse: in the new Gmail compose window, not even Command-Left/Right works (it does in other Textareas - no idea what Google did here).
Now this might totally be a case of http://xkcd.com/1172/ but by the life of me, I cannot work without a way to move the cursor to the beginning of a line - especially when the keys that I usually use are so destructive (scrolling all the way to the top, making me lose my position).
This is the only reason why using Firefox is out of the question.
In the past, I patched some JS file inside the bundle, but now that Firefox updates so often and it's a signed binary, I can't really do that any more.
You can do that using a custom key binding in ~/Library/KeyBindings.
Firefox ignores this and still insists on home/end working on the full document. But even worse: in the new Gmail compose window, not even Command-Left/Right works (it does in other Textareas - no idea what Google did here).
Now this might totally be a case of http://xkcd.com/1172/ but by the life of me, I cannot work without a way to move the cursor to the beginning of a line - especially when the keys that I usually use are so destructive (scrolling all the way to the top, making me lose my position).
This is the only reason why using Firefox is out of the question.
In the past, I patched some JS file inside the bundle, but now that Firefox updates so often and it's a signed binary, I can't really do that any more.
>The one thing that drives me mad about Firefox on the Mac is it's Home/End behavior. Ever since migrating to the Mac, I have remapped the keys to work like on windows and Linux (operating on the current line instead of the current document)
That's because Home and End keys on the Mac, like in the original UNIX, mean the beginning and the end of the document not the beginning and end of a line which is a Windows thing (and since Windows is the overwhelming presence, is commonly misunderstood as the keys themselves meaning that) and since most early Linux desktop environment's aimed to duplicate Windows, is also the default Linux behaviour now.
You will find this behaviour in all Apple provided applications as well.
> I cannot work without a way to move the cursor to the beginning of a line
Anything that doesn't override Cocoa's default key bindings will be able to use the emacs key bindings as well (Cntrl-A for the beginning and Cntrl-E for the end of the line)
>in the new Gmail compose window, not even Command-Left/Right works
cntrl-a and cntrl-e work.
That's because Home and End keys on the Mac, like in the original UNIX, mean the beginning and the end of the document not the beginning and end of a line which is a Windows thing (and since Windows is the overwhelming presence, is commonly misunderstood as the keys themselves meaning that) and since most early Linux desktop environment's aimed to duplicate Windows, is also the default Linux behaviour now.
You will find this behaviour in all Apple provided applications as well.
> I cannot work without a way to move the cursor to the beginning of a line
Anything that doesn't override Cocoa's default key bindings will be able to use the emacs key bindings as well (Cntrl-A for the beginning and Cntrl-E for the end of the line)
>in the new Gmail compose window, not even Command-Left/Right works
cntrl-a and cntrl-e work.
> You will find this behaviour in all Apple provided applications as well.
not on my machine. As I said, I used ~/Library/KeyBindings/DefaultKeyBinding.dict to change it. If the OS provides a way to change defaults, I expect applications to respect that too - no matter the historical reasons.
> >in the new Gmail compose window, not even Command-Left/Right works
> cntrl-a and cntrl-e work.
Yes, but Command-Left/Right is something that worked on the Mac even since before OSX. I, again, see no reason why it wouldn't work here.
not on my machine. As I said, I used ~/Library/KeyBindings/DefaultKeyBinding.dict to change it. If the OS provides a way to change defaults, I expect applications to respect that too - no matter the historical reasons.
> >in the new Gmail compose window, not even Command-Left/Right works
> cntrl-a and cntrl-e work.
Yes, but Command-Left/Right is something that worked on the Mac even since before OSX. I, again, see no reason why it wouldn't work here.
If the application overrides the defaults (which is fairly common ), your changing the defaults does nothing (for that application and for the keys that might have been overridden). It sounds like Firefox overrides the defaults completely but in it's override "map" keeps some of the functionality the same as the default.
I havn't used it but this claims it will change the Firefox behaviour as well (specifically make them behave like windows for the home and end keys)
https://addons.mozilla.org/en-US/firefox/addon/keyfixer/
I think cmd-left and cmd-right are used by Firefox for " back" and "forward" so those never work on Firefox (unless perhaps you go find where Firefox specifies its key bindings and change them)
I havn't used it but this claims it will change the Firefox behaviour as well (specifically make them behave like windows for the home and end keys)
https://addons.mozilla.org/en-US/firefox/addon/keyfixer/
I think cmd-left and cmd-right are used by Firefox for " back" and "forward" so those never work on Firefox (unless perhaps you go find where Firefox specifies its key bindings and change them)
Better link
http://www-archive.mozilla.org/unix/customizing.html#keys
sounds like
cmd_beginLine cmd_endLine
are what you need to modify in the example given
http://www-archive.mozilla.org/unix/customizing.html#keys
sounds like
cmd_beginLine cmd_endLine
are what you need to modify in the example given
<binding id="editorUser">
<handlers>
<handler event="keypress" key="w" modifiers="control"
command="cmd_deleteWordBackward"/>
</handlers>
</binding>>That's because Home and End keys on the Mac, like in the original UNIX, mean the beginning and the end of the document not the beginning and end of a line which is a Windows thing
Is it? I'm used to them going to the beginning and the end of lines on Linux.
Is it? I'm used to them going to the beginning and the end of lines on Linux.
The very next line you quoted tells you why that is the case on Linux now. if you used Linux in the late 90's, you will remember that a lot of the popular window managers/desktop environments aimed to make your transition from Windows 95 easier and the current Linux behaviour is a result of that.
I'm not talking about GUIs. I mean in text editors and at the Terminal.
>and since most early Linux desktop environment's aimed to duplicate Windows, is also the default Linux behaviour now.
> ...new Gmail compose window, not even Command-Left/Right works (it does in other Textareas - no idea what Google did here)
It drives me crazy too. At one point I used a workaround mentioned in the bug discussion[1], but I have no idea if it still works. I decided to support Mozilla/Firefox and just got used to control+a/e within Gmail.
[1]https://bugzilla.mozilla.org/show_bug.cgi?id=289384#c63
It drives me crazy too. At one point I used a workaround mentioned in the bug discussion[1], but I have no idea if it still works. I decided to support Mozilla/Firefox and just got used to control+a/e within Gmail.
[1]https://bugzilla.mozilla.org/show_bug.cgi?id=289384#c63
CMD-Arrow (left,right,up,down) will move you to the beginning of the line, end of line, start of document,end of document respectively. I really miss these keys when I am on windows as I find it much less of a hand movement to do.
Yeah. It just doesn't work in Gmail's new compose window in Firefox. No idea why.
Home/End go to the beginning/end of a page on linux/windows. (Unless you are referring to the behaviour in a text area).
We're actually very far along in implementing what you saw in those screenshots.
You can download a Nightly build of it (that auto-updates) at http://people.mozilla.org/~jwein/ux-nightly/
You can download a Nightly build of it (that auto-updates) at http://people.mozilla.org/~jwein/ux-nightly/
Since Camino is based off Firefox, is it possible to backport some of the OS X specific code? The primary reason why I'm still using Safari rather than Firefox is because it lacks Keychain support.
There have been two attempts that I know of (and probably more) to add keychain support to Firefox, once leveraging Camino’s code. The problem wasn't technical, but resistance from Firefox leadership to the idea. IIRC they were concerned about breaking the ability to move a profile folder from one OS to another.
Couldn't disagree more. I think Firefox looks and feels great.
I'm not a Mac fanatic, which might be why I prefer FireFox on Mac to other browsers.
Aw. Camino was awesome back in the day. Thanks to the developers for making the best browser for Mac at the time.
I worked on Camino quite a bit in the early 2000s, it was a great experience. It's funny to think that we really felt we were contributing greatly to the appeal of Mac OS X by providing the kind of browsing experience Apple should have provided on the OS much earlier, given their focus on it being designed with the Web in mind.
Eventually Mozilla hired me to help re-write the Firefox port to Mac OS X because the product lagged so far behind Camino. Once I got deep enough into that project my Camino contributions dropped off. Dedicated volunteers carried on. I had forgotten that they still hadn't shut it down yet.
Anyway, congrats to Camino on the long run! It was a great option, particularly for earlier Mac OS X users, and a joy to work on.
Eventually Mozilla hired me to help re-write the Firefox port to Mac OS X because the product lagged so far behind Camino. Once I got deep enough into that project my Camino contributions dropped off. Dedicated volunteers carried on. I had forgotten that they still hadn't shut it down yet.
Anyway, congrats to Camino on the long run! It was a great option, particularly for earlier Mac OS X users, and a joy to work on.
One feature Camino ha and that I really miss in other browsers is that it displayed whether files in its download window were still there. That sounds rather trivial, but made it a perfect "file inbox", where I could quickly see whether I still needed to review/move a file.
And the fact that it was more in sync with the OS X desktop experience than Firefox (back in the days; got better) and Safari (brushed metal)...
Of course nowadays, a hierarchical tab sidebar is my one "exclusive" killer feature, and as of yet only Firefox has that (via add-ons).
And the fact that it was more in sync with the OS X desktop experience than Firefox (back in the days; got better) and Safari (brushed metal)...
Of course nowadays, a hierarchical tab sidebar is my one "exclusive" killer feature, and as of yet only Firefox has that (via add-ons).
Chrome does that download behavior as well. You can see if a file has been removed from the downloads folder right from the downloads tab in Chrome.
They lost such a good chance to say "Es el fin del Camino!" (which means "Is the end of the Road!" in Spanish)
Well that marks one more end of an era. With Camino folding up and Opera going with WebKit - Camino too was on the way to this with Gecko being out of the question - the browser field is getting to be a one-horse race (since all the cool kids are going with Chrome these days).
Arguable. Jolla uses Gecko with IPC embedding for their upcoming browser for Sailfish. Gecko is in no way out of the question. Mozilla are also working on the new Rust based browser engine (Servo).
That's news to me.
nitpick: Opera is going with Blink. Admittedly, Blink is very similar to WebKit at the moment.
> nitpick: Opera is going with Blink. Admittedly, Blink is very similar to WebKit at the moment.
Actually, Opera is leveraging Chromium—not just Blink. This includes the rendering engine (Blink), V8, networking, etc, etc.
Actually, Opera is leveraging Chromium—not just Blink. This includes the rendering engine (Blink), V8, networking, etc, etc.
I only stopped using Camino when I became dependent on some Firefox extensions (AdBlock, NoScript, eventually others). The big downside to Camino having a fully native UI was that it didn't have XUL support, so no cross-compatibility with FireFox extensions.
As soon as one of the Mac-compatible WebKit browsers can replicate the functionality of AdBlock Plus, NoScript, and BetterPrivacy, I'll quit using FireFox on OS X, because it's still noticeably non-native and has some persistent annoyances.
As soon as one of the Mac-compatible WebKit browsers can replicate the functionality of AdBlock Plus, NoScript, and BetterPrivacy, I'll quit using FireFox on OS X, because it's still noticeably non-native and has some persistent annoyances.
AdBlock Plus is available for Chrome and NotScripts replicates NoScript. I'm not sure what BetterPrivacy gets you that you can't do yourself by changing your cookie settings.
Notscripts hasn't been updated since December of 2010. ScriptSafe (used to be scriptno) is still being developed https://chrome.google.com/webstore/detail/scriptsafe/oiigbmn...
However, the author of noscript has said that it isn't technically possible to entirely replicate all of the features of noscript on chrome because extensions on chrome don't have the same kind of access as they do on firefox.
http://hackademix.net/2009/12/10/why-chrome-has-no-noscript/
However, the author of noscript has said that it isn't technically possible to entirely replicate all of the features of noscript on chrome because extensions on chrome don't have the same kind of access as they do on firefox.
http://hackademix.net/2009/12/10/why-chrome-has-no-noscript/
Betterprivacy can kill flash cookies.
NotScripts is still only mitigating JS and not fully blocking it, at least last time I looked at the source (I also almost puked). Plus it lacks feates like clear click (anti clickjacking), ABE etc.
NotScripts is still only mitigating JS and not fully blocking it, at least last time I looked at the source (I also almost puked). Plus it lacks feates like clear click (anti clickjacking), ABE etc.
Camino was my preferred browser on my old Macbook because it was the simplest and most easy to use browser available. All other browsers were irritatingly complex by comparison.
Unfortunately/fortunately with browsers becoming more of an OS replacement, it makes it rather hard if not impossible for small teams to maintain them.
Aside from that, Mozilla backed out Gecko embedding a long time ago, which is why Camino still operates with a Firefox 3.6 Gecko. That makes maintainership futile when the browser can only fall further and further behind on its ability to simply render websites.
My opinion is that Google/Mozila is pushing HTML5 instead of plugins not because that's what's best for the web, but because exactly this-- it decreases the potential for competition.
If you really want to get a good conspiracy theory going, note that a lot of the main Camino people have worked at Google for many years now (longer than Chrome has existed), and the other main person went to Apple.
I think this is the first time I've ever heard anyone accuse Mozilla of stifling competition.
They must be quite bad at it, because both their browsers are split into components that can easily be reused in competing products.
The whole reason Camino has been discontinued is that the components that make it easy to reuse Gecko in their competing product were removed from Gecko.
I'd like to see your source for that claim. At first glance it seems that popularity of Camino, both among its developers and its users, has been declining for years.
A big counter-example is Opera Software switching away from their own engine to WebKit/Blink.
A big counter-example is Opera Software switching away from their own engine to WebKit/Blink.
http://caminobrowser.org/blog/2011/#mozembedding
Opera has a paid staff of full-time engineers, which makes rewriting a browser on top of a new engine a lot more feasible.
You're right in that if Camino had the developer time it had in its heyday it might have made the jump and survived, but the end of Gecko embedding is what made it impossible for Camino to continue to be maintained indefinitely by one or two people.
Opera has a paid staff of full-time engineers, which makes rewriting a browser on top of a new engine a lot more feasible.
You're right in that if Camino had the developer time it had in its heyday it might have made the jump and survived, but the end of Gecko embedding is what made it impossible for Camino to continue to be maintained indefinitely by one or two people.
This is why opera is now using chromium.
I remember Camino running really well on my old Powerbook and also looking great. Farewell, friend!
A sad announcement, but the writing has been on the wall for a few years now (specifically, since Mozilla officially dropped support for embedding[0]).
I'm only surprised they waited this long to make it official.
[0] https://groups.google.com/forum/#!topic/mozilla.dev.embeddin...
I'm only surprised they waited this long to make it official.
[0] https://groups.google.com/forum/#!topic/mozilla.dev.embeddin...
Would it be such a sin to continue to use it for a while practicing safe browsing techniques? Or am I naive to think that I can avoid being harmed browsing trusted sites with my beloved browser?
Seemed to be a favorite for marketing campaigns thanks to it's minimal interface.
Camino will be missed.
Seemed to be a favorite for marketing campaigns thanks to it's minimal interface.
Camino will be missed.
your primary risk would be bad networks serving up malware, which is pretty hard to defend against
Here is the post from the most recent maintainer on his blog: http://samuelsidler.com/2013/05/the-end-of-an-era/
Thanks to all the devs who have worked on Camino over the years.
Thanks to all the devs who have worked on Camino over the years.
Such a great browser back in the day. It was absolutely my preferred browser of choice until Chromium came to the Mac.
I used Camino since the beginning and I still have it installed my old iMac desktop. To me, it felt more like a Mac OS Browser than Safari.
I've switched my main browser from Safari to Chrome to Firefox, but I always kept Camino around. It's going to bum me out to delete it finally.
I've switched my main browser from Safari to Chrome to Firefox, but I always kept Camino around. It's going to bum me out to delete it finally.
A shame the energy that went into Camino didn't go into MacFirefox.
It seems like XUL required ten times as much effort to get comparable results.
Fine, then make XUL better on Mac. But for the love of god, don't (obviously) waste so much precious energy on a (obvious) dead end.
XUL was only part of the problem. Camino's goal was to make a browser that was designed for the Mac. Firefox's goal (once running on the Mac was added after the fact) was to make a cross platform browser that ran on the Mac. That's not just about UI toolkits, it drives basic decisions.
Firefox doesn't use Keychain because cross-platform trumped integration. Its localization (a different download for every language, instead of one multi-language binary like every Mac app) is "wrong" for the same reason. It doesn't integrate with the Me card in Address Book for form fill data for the same reason. It makes you set your accept-language list manually instead of using the identical OS-level list for the same reason. The list, some small and some large, goes on, and it all adds up.
It affects UI behaviors too. I don't know if they eventually fixed it, but for a while closing the last window would quit the app, which is against the platform guidelines for a multi-window app, and was widely hated by Mac users. The justification was that it was consistent with Windows Firefox.
Those of us who chose to work on Camino in our free time did so because it was the product we wanted to build, and Mac Firefox was clearly never going to be no matter how much effort we might have put into it. You can call it a waste if you like, but I think you'd be hard pressed to find someone who worked on Camino who regrets the time they spent on it, or considers it a waste.
As for it being an "obvious dead end", until Gecko embedding was deprecated there was no reason Camino couldn't have continued indefinitely. How is developing software that many people still love and use a dead end? Not everyone in the world views dominating the market as the definition of success.
Firefox doesn't use Keychain because cross-platform trumped integration. Its localization (a different download for every language, instead of one multi-language binary like every Mac app) is "wrong" for the same reason. It doesn't integrate with the Me card in Address Book for form fill data for the same reason. It makes you set your accept-language list manually instead of using the identical OS-level list for the same reason. The list, some small and some large, goes on, and it all adds up.
It affects UI behaviors too. I don't know if they eventually fixed it, but for a while closing the last window would quit the app, which is against the platform guidelines for a multi-window app, and was widely hated by Mac users. The justification was that it was consistent with Windows Firefox.
Those of us who chose to work on Camino in our free time did so because it was the product we wanted to build, and Mac Firefox was clearly never going to be no matter how much effort we might have put into it. You can call it a waste if you like, but I think you'd be hard pressed to find someone who worked on Camino who regrets the time they spent on it, or considers it a waste.
As for it being an "obvious dead end", until Gecko embedding was deprecated there was no reason Camino couldn't have continued indefinitely. How is developing software that many people still love and use a dead end? Not everyone in the world views dominating the market as the definition of success.
Could they not turn the development over to the community? Put the source code up on Github? Seems a shame to kill it off.
*I'm not a user and not sure how popular the browser is.
*I'm not a user and not sure how popular the browser is.
Camino has been open source and developed entirely by a community of volunteers for most of its life. There were extensive instructions on getting involved on the website for many years. There was even a specific push to recruit new people a year ago to make the transition to WebKit so that it could continue to use a modern engine, which is the only way it could have survived once Gecko stopped supporting embedding.
If there were a community of people with the time/interest/skill to develop it further, the project wouldn't have shut down in the first place.
If there were a community of people with the time/interest/skill to develop it further, the project wouldn't have shut down in the first place.
They should definitely add this to the frontpage.
I didn't even know this existed until this post happened.
I learned about it just last year and forgot about it again until today. It's just not even much of an option if we're going to be honest, unless you want a minimal experience.
I think it was the only browser that really gelled with the 'Aqua' UI style. IE for Mac did so too, to an extent, but Camino had more advanced features.
I used Camino for a year or two. It wasn't much of a choice, run Omniweb or Camino.
Anyone else remember when Camino was Chimera?
Anyone else remember when Camino was Chimera?
Anyone still using OmniWeb these days?
Still the go-to browser for the diehards on NS/OS, I hear. I remember figuring out how to plumb in SSL and JS support just so I could access a butchered Dropbox...
Perhaps Mr. Shipley?
Thank you for your contribution to the Mac community
[deleted]
Give Opera Next a chance. I have been using it since it came out and although it has a couple rough edges it feels more user focused than Chrome.
One rough edge is that it totally ignores my keyboard layout for keyboard shortcuts. It appears to use the Qwerty layout for shortcuts, even under a different layout.
(That's Opera next 12.50 on Linux, with Presto)
(That's Opera next 12.50 on Linux, with Presto)
“Camino is not receiving security updates” “Camino reaches its end” “Camino is no longer being developed”
I don’t like the tone of this press release. They make it seem like they’re not responsible for the lack of updates and that Camino died a natural death. They didn’t offer an explanation nor did they give any advance notice. Not very classy.
I don’t like the tone of this press release. They make it seem like they’re not responsible for the lack of updates and that Camino died a natural death. They didn’t offer an explanation nor did they give any advance notice. Not very classy.
From http://caminobrowser.org/blog/2011/#mozembedding
As a purely community-based open source project, no one is employed to work on Camino; all Camino developers are volunteers, working on Camino in their spare time, as a labor of love. While maintaining embedding in a fork of Gecko is theoretically possible, we don’t have the manpower for a sustained effort of that kind
As a purely community-based open source project, no one is employed to work on Camino; all Camino developers are volunteers, working on Camino in their spare time, as a labor of love. While maintaining embedding in a fork of Gecko is theoretically possible, we don’t have the manpower for a sustained effort of that kind
Ah, that explains a lot. It also shows the shadow side of open source software development: if the developers get bored, they can just up and leave. If all the devs do so, the project is dead but there’s no one there to call it. Users aren’t owed any explanation.