Camino browser reaches its end(caminobrowser.org) |
Camino browser reaches its end(caminobrowser.org) |
* puts on shades * Reached the end of the road!
* Cue the CSI theme * YEAHHHHHHHHHHHHHHHHHH!!!!!!
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.
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
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.
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.
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:
I'll miss Camino.
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.
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).
Actually, Opera is leveraging Chromium—not just Blink. This includes the rendering engine (Blink), V8, networking, etc, etc.
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.
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/
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.
I'm only surprised they waited this long to make it official.
[0] https://groups.google.com/forum/#!topic/mozilla.dev.embeddin...
Seemed to be a favorite for marketing campaigns thanks to it's minimal interface.
Camino will be missed.
Thanks to all the devs who have worked on Camino over the years.
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'm not a user and not sure how popular the browser is.
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.
Anyone else remember when Camino was Chimera?
(That's Opera next 12.50 on Linux, with Presto)
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.
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 download a Nightly build of it (that auto-updates) at http://people.mozilla.org/~jwein/ux-nightly/
What if you only needed to implement html1.0 and NPAPI?
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.
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. :\
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.
A big counter-example is Opera Software switching away from their own engine to WebKit/Blink.
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.
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.
So it can only be used as a direction indicator and as such, I think it looks good.
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.
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...
They do have MS-Office ports for Mac, so that product was probably written with much better separation of concerns.
BTW, the UX alpha is back to the old style.
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.
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.
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)
Is it? I'm used to them going to the beginning and the end of lines on Linux.
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.
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>