Examining Chrome's Source Code 288
An anonymous reader writes "Chrome is open source, and there's clearly still some work to be done on it. In this article, Neil McAllister decided to take a peek under Chrome's hood and view it through the eyes of the developers who will improve and maintain it in the coming years. It seems Google's open source browser currently has much to offer prospective hackers — provided they use Windows. Quoting: 'The Chromium site explains how to download the source code for Linux, Mac OS X, or Windows. Unfortunately, if you're eagerly awaiting a Mac version of Chrome, you shouldn't hold your breath. As the Mac OS X area of the Chromium developer site explains, "Right now, the Mac build is a work in progress that is much closer to the start than the finish." In fact, according to the latest status report, the Chrome developers have yet to get even the browser core running under Mac OS X. Rendering actual Web pages is still a long way off, to say nothing of a usable Aqua GUI. Then again, the Linux version is in arguably even worse shape.'"
the core not even running under mac? (Score:4, Insightful)
Re:It's not over for Mozilla after all (Score:5, Insightful)
And google is really happy with that. They don't need to target the linux market because Mozilla is already working for them here.
The target is obviously internet explorer.
Re:What I don't get... (Score:5, Insightful)
Cross-platform widget sets are always dreadful. An application developed using cross-platform widgets will, at best, work well on one platform, and more usually on no platforms. OS X and Windows have different UI philosophies, and an OS X application needs a different UI from a Windows application.
Re:It's not over for Mozilla after all (Score:5, Insightful)
Re:It's not over for Mozilla after all (Score:1, Insightful)
Google has their Desktop applications for Windows.
Competes with Internet Explorer and other Microsoft products directly,
Co-operates with Firefox and Safari, etc.
I'm too tired to think straight really.
Travesty (Score:4, Insightful)
Google had the chance to show openness, platform independence, support for Open Systems principles and designs, and true independence from Microsoft control with Chrome, but lost it. If ever there were an important time to make sure of a simultaneous, multiplatform release, this would have been it. Instead, we have a typical "release for the largest platform" with weak promises of eventual support for everyone else. That isn't a good message for 2008; it doesn't match the "visionary" of what they are trying to do with Chrome.
Google irritated a large number of users that would have been most likely to try and promote Chrome and to give contributions to the code- those NOT using MS-Windows. I think it was a huge mistake they didn't hold the release until there was a reasonable set of code for all the three major platforms. Given Google's resources, I doubt it would have been all that difficult.
I have talked to many Linux and MacOS users about Chrome- most are disappointed, some extremely disappointed, and many are quite bitter, too. You can't blame them for being unhappy... and this article indicates that seeing Chrome on Linux and MacOS is nowhere near "right around the corner".
Re:Does it really matter? (Score:5, Insightful)
They've surrounded the tasty nugget of Mac-compatible Webkit code with a thick layer of Windows-only user-interface and thread-maintenance code.
Re:What I don't get... (Score:4, Insightful)
Not that different really. Qt does a very cross-platform good job, and several other toolkits do a more-than-passable job as well such wxWidget or FLTK.
To me cross-platform is the only way to go, if you don't want your code to obsolete itself in no time at all.
Re:What I don't get... (Score:5, Insightful)
So they want to develop a cross-platform browser.
Not really - they want a Windows browser to deliver their apps on which, largely thanks to the Google name, might stand a chance of making some inroads against IE.
Mac and Linux versions would be nice too - but those users already use either Firefox or Webkit/Safari which have a better reputation for standards compliance and aren't controlled by Microsoft. That last is particularly important if your name is Google and you produce webapps which compete with Microsofts office products.
So why again is the Mac port "closer to start than finish"
Because they obviously chose to develop for Windows and port later, rather than develop all 3 versions in parallel. So maybe they delayed the Mac and Linux versions at the expense of Windows, but the upshot is that they got the Windows beta out before IE8 launches. Kinda strategic.
Chrome is based on Webkit
So what if they don't have to write WebKit for Mac? They didn't have to write WebKit for Windows, either! What Google are spending their time on will be the not insubstantial bits that wrap around Webkit to make it Chrome.
it's not like there aren't any cross-platform widget sets out there
Looks to me like they're using their own Widget set. Plus (as both MS and Mozilla have found in the past) Mac users tend to come down hard on apps that don't look as if they were born and bred on a Mac.
Re:What I don't get... (Score:3, Insightful)
I don't see how POSIX is even introduced as a reason it should work, at least for Windows. I've never heard of it being useful in Windows except for command line software, that it precluded even using a GUI. I recall it was put in to satisfy a checklist for government purchases, only rarely being useful for anything other than that.
Re:Does it really matter? (Score:3, Insightful)
Yes it matters, because competition spurs progress. Just look at how IE stagnated until Firefox started to take market share.
Re:Sandbox (Score:3, Insightful)
Dude, they freaking bought GreenBorder, one of the original companies that does sandboxing for normal Winblows executables.
What makes you think they have to rip off anyone?
Re:It's not over for Mozilla after all (Score:5, Insightful)
But of the eleventy billion IE users who still haven't switch to !IE, why would they switch to Chrome? I think the vast majority of them can be split into two groups: their bank/intranet/some stupid thing/fucking activex/etc doesn't work right elsewhere, and "the blue e takes me to the internet!". The first group can't switch and the second just doesn't care - why/how would Chrome change that?
Re:It's not over for Mozilla after all (Score:2, Insightful)
Re:Where is my Google Talk for MACOSX (Score:3, Insightful)
Truly, wtf? (Score:5, Insightful)
It's a really confusing situation that in my eyes loses them serious geek points. Hell, use
As for the old argument that nothing cross-platform can look good: eclipse.
Re:Not really interesting... (Score:3, Insightful)
Of course, IE7 then came out, with every new "innovation" basically being a copy of whatever made Firefox unique
Hardly unique. IE7 didn't rip anything off Firefox that Opera hadn't had for years before either Firefox or IE7.
Re:It's not over for Mozilla after all (Score:4, Insightful)
I've tried removing the icon on her desktop, but that just makes her confused and annoyed =P
So make a firefox shortcut with the IE icon. :P
Re:Truly, wtf? (Score:3, Insightful)
It's because google insists on writing cross platform apps that are actually native, and dont look like crap. These considerations don't apply to most open source cross platform apps, which take the lazy way out and use gtk, qt, or some other cross platform widget set, to the users' dismay.
Re:It's going to have maintainability problems. (Score:3, Insightful)
Re:Truly, wtf? (Score:3, Insightful)
What is it with google and their inability to write cross-platform GUI's? If nearly every OSS app can do it, why can't google?
'Every OSS app' generally uses GTK+ or QT; GTK+ looks like ass on Windows, and doesn't look or feel the way it's supposed to. It also doesn't work at all on OS X (and if anyone mentions X11 I'll put a fork in your eye).
QT works on Windows and Mac; it only kind-of 'fits in' on Windows because all Windows apps tend to look and behave differently anyway, and it kind-of works on Mac the same way GTK+ works on Windows - poor but functional.
The only OSS apps I've ever seen that look and work well on the Mac are the ones that were written specifically for the Mac - for example, Adium. Firefox is getting better (3.0 is a huge step up), but even Camino, a native Mac application using the Gecko rendering engine, doesn't feel like a Mac app to me.
As for Windows, there's not a lot of good open-source software there. Again, Firefox can be found, and it's not too bad, and there's always Pidgin, which just seems horribly hackish to me, but on Windows apps tend to fit in only because there's no overarching sense of style or functionality that determines how apps should work or behave.
'Nearly every OSS app', if it works at all cross-platform, is garbage on every platform that isn't Linux. And before you say 'at least they could make it run on Linux then!' remember that OS X has significantly higher market share than Linux does, and likely ever will, on the desktop - and they likely fully expect Linux users who really want it to help them port it.
Besides, they don't gain anything from pulling users away from Firefox or Safari, and making their idea better than those browsers' benefits (extensions on Firefox, speed and platform-nativity for Safari) would be a lot more work than just making a browser that's far better than IE.
Re:It's not over for Mozilla after all (Score:5, Insightful)
And give the developers of that site an excuse to keep producing bad code?
I think not.
int to pointer (Score:3, Insightful)
Because they did what one should not do: convert integers to pointers and vice versa. This only works well when the size of an an integer is the same as the size of pointer. This was true for 32 bit CPUs and programmers got used to it. (it wasn't for 8 bit and most of the 16 bit CPUs).
As the 32 bit area was so long programmers got used to it. And the fact that an int is 32 bit. In the end compiler designers where between the devil and the deep blue see. Either make int same size as a pointer 64 bit - and break existing code relying on 32 bit integer or make the in in 32 bit and break existing code relying int beeing the same size as pointer.
Personally the ease of converting integer to pointer is one of the top 3 design mistakes in C (which carried across to C++). Don't get me wrong: A system level programming language needs such a conversion. It just should not be so easy - it should be painful to use so it is not overused.