Google Announces Chrome For Mac and Linux Dev Builds
Dan Kegel (who admits to being a Chrome developer) writes to point out a post from Mike Smith and Karen Grunberg, Product Managers for Google Chrome, with some good news for non-Windows users who want to play with Chrome: "In order to get more feedback from developers, we have early developer channel versions of Google Chrome for Mac OS X and Linux (for a couple of different Linux distributions), but whatever you do, please DON'T DOWNLOAD THEM! Unless of course you are a developer or take great pleasure in incomplete, unpredictable, and potentially crashing software." (The announcement continues below.)
"How incomplete? So incomplete that, among other things , you won't yet be able to view YouTube videos, change your privacy settings, set your default search provider, or even print.
Meanwhile, we'll get back to trying to get Google Chrome on these platforms stable enough for a beta release as soon as possible ..." The downloads are available through the Chrome developer's channel.
Meanwhile, we'll get back to trying to get Google Chrome on these platforms stable enough for a beta release as soon as possible ..." The downloads are available through the Chrome developer's channel.
But they aren't... SEPARATED INTO PROCESSES!
OK, seriously and drama aside, I do think that's a good idea, and it also seem to help as a way to help out with memory management. I always thought Safari sucked a lot of RAM, especially on Windows.
Beware: In C++, your friends can see your privates!
I just installed the .deb on this laptop, running Ubuntu 9.10 alpha. So far, seems nice and pleasant :)
I seem some rendering problems, but Hey, I blame google!
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
Two issues are being confused there. First, do you use a cross-platform toolkit, or do you write a true native GUI for every platform and just keep the backend in common? Google have decided to write a new GUI for every platform, and I think they are probably correct to do this. Qt (and GTK+) are cross-platform, but they are not quite native (though arguably Qt is better at this).
Once that choice is made, all you are doing is picking a toolkit for Linux. GTK+ has the advantages of being familiar to the chrome devs, matching the existing ff dependency, being the most widely-used toolkit (and therefore appearing native for the largest number of users), and being "good enough".
I have been following chrome for mac development closely on my blog with weekly updates. Here is a list of the functionality as of Build 17426
What Works
* Almost All Websites
* Bookmark pages
* Most visited sites
* Open link in new tab
* Open new tabs
* Omnibox
* Back, Forward, Reload
* Open link in new window
* Drag a tab to make a window
* Launch new tab
* Cut, Copy, Paste
* Keyboard shortcuts
* about:version, about:dns, about:crash, about:histograms
* Find in page
* History with search
* Form Fill
* Delete Thumbnail in New Tab Page
* Window Positions Remembered
* View Source with synatx highlighting and clickable links
What Doesn't Work
* Plugins (No flash -> No youtube)
* Bookmarks Bar
* Print
* about:network, about:memory
* Web Inspector
* Input methods such as Kotoeri (Japanese)
* Preferences (Partial implementation)
* Full Screen Browsing
* Favicon (thanks brin)
TechSutra
I'm not current on development for the Mac, but I've heard that multiple processes can't share a single window in OS/X.
Do you happen to know how Chrome works around this, or is this not an actual limitation?
I'm not a mac dev and what i'm posting here is gleaned from several svn log entries. So it might be wrong and inaccurate :). The chrome architecture is that there is a main process which handles the UI and there is one process per site which is launched but do not handle the UI. In Mac, the one process per site works but if you open up Activity Monitor you will see that the additional processes are shown as "Not responding" though in reality they are.
What is happening here is that OS-X expects the additional processes to respond to UI events and since they don't mark them as "Not Responding". Two solutions have been proposed
1. have dummy code which responds to UI events to keep OS-X happy
2. Rip out the Cocoa code from the additional processes which will make OS-X not expect the process to respond to UI events.
TechSutra
A friend wrote up a Gentoo ebuild for it, which I went and installed (for the amd64 version - I run an almost entirely 64 bit system). Try to run it, and got this message:
That's odd ... double check ... yes, /usr/lib64/libgconf-2.so.4 exists ... No ... they couldn't have ...
$ file /opt/google/chrome/chrome
/opt/google/chrome/chrome: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
*facepalm*
The 64-bit Chrome is *NOT* 64-bit, and will not run on 64-bit systems which are missing a number of 32-bit libraries.
Last time I checked, chrome, firefox, safari all did this?