TAG | A Linux users' guide to Google Chrome |
|
| by David M Williams | |
| Thursday, 04 September 2008 | |
|
Page 3 of 3 Navigate into the src subdirectory; here’s where – obviously enough – all the Chrome source code is held. There are a series of folders here. The first is base which appears to contain the important underlying data structures that make up the basis of Chrome’s fundamental design.Featured Whitepaper
5 Best Practices for Smartphone Support
Additionally, this is where routines exist to interact with the file system. You can see work has begun on the Linux port; it’s here where operating system distinctions most come into play necessitating specific code for each platform. There are four Linux specific files to be found here, base_paths_linux.cc and base_paths_linux.h, file_util_linux.cc and sys_string_conversions_linux.cc. (Incidentally, there are MacOS variants to be found here too.) These cater for the differences between file and path separators, the method in which strings are encoded and other low-level but fundamental elements. Moving along, some other folders in the src directory implement Google specific functionality; gears is binary only – with just a Windows DLL at this time – and adds support for Google Gears. The google_update folder implements support for a Google service that notifies of available updates; no doubt this will provide a facility akin to Windows Update and Apple Software Update as used to fetch new releases of Internet Explorer and Firefox so that Chrome users can always stay on top of the release cycle. (That will update the binary version; we’ve sorted out keeping the source code up-to-date above, but this manages the executable version for end users without having to muck around with building the code for themselves.) The third Google folder, googleurl, implements a library which offers fast URL parsing. Undoubtedly this could be leveraged by other software developers; it’s not Chrome-specific. In fact, its accompanying README specifically says it was designed so as to be easily embeddable in client and server programs. Google allege their library is blistering fast. Other miscellaneous pieces of code are festooned about; some offer only a hint of explanation (such as breakpad, whatever it is, is provided as a Windows executable only) and some aren’t immediately obvious (like sdch which is utility code to implement fast on-the-fly compression) but others need little introduction. Specifically, the source code folders v8 and webkit, which make up the two major bodies of external work being employed by Google and credited by them as much of the success behind Chrome (beyond their own innovative multi-process concept.) The folder third_party is a potpourri of miscellaneous small libraries and utility apps. Some of these provide support for image rendering (libjpeg and linpng for instance), some for parsing (libxml) and some for actually building the whole thing (scons, the system which was invoked to build the code above.) There’s certainly a richness of program code and functionality to be found in the src folder and it hints at why a Linux version is not yet ready (because there’s not yet a Linux build of certain pre-requisites like Google Gears included), and what will be included by virtue of libraries and dependencies to be found. Additionally, there are elements which are of certain value to other developers like the Google URL parsing library. In fact, that’s one of the beauties of open source software. Just as Google have borrowed from the work of others so too they encourage others to share ideas from them. Whereas it may be disappointing there is no Linux version available yet if you’ve downloaded the source repository you’re now in a good position: by periodic synchronising the source tree and attempting a build you can follow the progress of the developers quite literally as soon as they check-in their work to Subversion. |
Tags
| < Next story in category | Previous story in the category > |
|---|
