Google Earth Beta for Mac

Thijs van As writes "AppleInsider reports that Google is developing a Google Earth version for Mac OS X. From the screenshots it looks similar to the Windows version, which is out since June 2005. The OS X version uses OpenGL rendering." From the article: "Earlier this month, a pre-release version of Google Earth for Mac OS X that uses OpenGL rendering reportedly began making the rounds overseas. The 40MB application packs a hefty set of preferences, allowing users to tweak detail and color, and control the speed of their 'flights.' Google Earth interfaces with Google's Web-based mapping service, Google Maps, in providing local search results and driving directions. However, sources say Google Earth for Mac OS X includes a superior set of satellite imagery when compared to the Google Maps Web service, offering additional clarity and a deeper zoom function."

Comments

Fell off the ugly tree and hit every branch.

[uiucmatse]

Whew, that is ugly. It looks like, I dunno, Limewire.

The tabs that haven't been used since 10.2, the cheesy movement controls, the ugly shiny candy headers on Places and Layers...

Well, at least it's not metal.

Re:Fell off the ugly tree and hit every branch.

[mapinguari]

Maybe the screenshot was taken with the app running on 10.2.

Re:Fell off the ugly tree and hit every branch.

[TheRaven64]

No, take a closer look at the title bars - they are the newer style which came in with 10.3, so the demo machine must be running at least 10.3 but still using 10.2-style controls. The only other time I've seen an app this ugly on a Mac, Qt was to blame - I hope this isn't the reason here, because if it is then looking ugly will be the least of its problems (Qt messes up the feel a lot worse than it messes up the look).

Re:Fell off the ugly tree and hit every branch.

[cacepi]

Whew, that is ugly. It looks like, I dunno, Limewire.

Could be worse; could be Internet Explorer.

Who cares? One less reason to use the PC!

Now if you can only enable monospaced text editing in GMail, Google, I'll be your friend for life.

Re:Fell off the ugly tree and hit every branch.

[SineOtter]

Looks pretty similar to the Windows version to me- Albeit with aqua tabs at the top.

Re:Fell off the ugly tree and hit every branch.

[byolinux]

Looks pretty similar to the Windows version to me

I think that's what they meant when they said ugly. ;)

Re:Fell off the ugly tree and hit every branch.

[Anonymous Coward]

Yup, it includes libqt.3.dylib. So yes, the controls are done via Qt/Mac. (I'm running 10.4.)

The "feel" seems OK, but the look is pretty bad -- the menus are also non-standard, including weird checkboxes, icons, etc.

Hey, it's a beta, so I'm gonna cut it some slack. I haven't seen if Qt/Mac v4 offers better controls, but I'm willing to remain optimistic. At the very least, if they use Qt, we'll see similar Windows, Linux and Mac versions of all the Google apps, all released at similar times.

Re:Fell off the ugly tree and hit every branch.

[Anonymous Coward]

That's just because it's using QT/Mac people. With QT/Mac you can't really do better than that (QT on the Mac is expensive and majorly sucks) - just look at apps like the PSI Jabber client. Now, everybody and dogs knew Google Earth is QT based (just look for the .dll's...) so, what else is new? (Linux-x86 will also end up being supported, once you're using QT and OpenGL that's not that hard to predict)

Re:Fell off the ugly tree and hit every branch.

[macmurph]

It looks a lot better than the old days when a big companie's Mac version looked like, I dunno, nothing, nada, and zip.

Re:Fell off the ugly tree and hit every branch.

[Anonymous Coward]

Apple don't provide ANY sort of cross platform libraries. And they don't support QT or Gtk the least. If you need cross platform single codebase you have to rely on third party tools on OS X. Thats why it's clunky for you, tell Apple to support cross platform OSS libraries better and you will see they can improve quite a lot.

Re:Fell off the ugly tree and hit every branch.

[TheRaven64]

Apple implement the OpenStep specification - a cross platform spec for development of GUI applications. Sun also provided an implementation at one point, and the GNU project provides one in the form of GNUstep, which runs happily on all UNIX variants I've encountered and only slightly less happily on Windows. I, and many others, have no problems developing cross-platform apps which look and feel native on OS X.

Re:Fell off the ugly tree and hit every branch.

[Anonymous Coward]

The beta is floating around on the net.
I've been using it. It looks fine and works very well.
The screenshots might be old.

Re:Fell off the ugly tree and hit every branch.

[Anonymous Coward]

Funny, nobody on Unix or Windows has ever seen those rumored OpenStep programs. Gnustep is a toy you can install to see what it can do, it's not production ready. It also doesn't look or behaves anything like native on any platform.

QT is way better for crossplatform use. Maybe Apple should try to help Trolltech to sort out the quirks.

ya, but does it run on linux?

[golgotha007]

Are they working on a Linux verison (with openGL)?

Re:ya, but does it run on linux?

[Anonymous Coward]

I'd think so. The Mac version that's circulating uses Qt, so presumably it'd be easy to release a version on Linux too.

I really don't care what it looks like...

[fyngyrz]

...I'm just happy to see it. While I enjoy pretty, what actually matters to me is functionality and reliability. And in this case, simply availability — this has been beta under Windows for quite some time already.

Too much focus on pretty can result in the "Hollywood Effect" —beauty without value, or worse, beauty that impacts value... like recent media player designs or the incredibly bad Kai's interfaces of yore. I've had enough of that kind of craziness.

Re:I really don't care what it looks like...

[moosesocks]

We're not talking about 'pretty' here. The main gripe the mac community has with programs like this is that they do not follow the conventions of a normal OS X user interface. A 'pretty' media player would have the same problem.

The strength of the Cocoa and Carbon windowing toolkits has allowed many first-rate applications to be developed without requiring the developers to resort to creating their own (ugly) controls. Windows has been guilty of this on many accounts, and microsoft's only beginning to make up for it with .NET. It's not uncommon to see custom UIs in Windows such as Winamp, GEarth, iTunes, Trillian, etc.... because the standard UI controls available are simply not sufficent to create a usable, streamlined application that's also visually appealing.

In contrast, GEarth could operate just fine using standard OS X controls and conforming to the OS X UI Guidelines. Using a standardized toolkit also has many nice perks like that drag-and-drop *always* works.

Re:I really don't care what it looks like...

[fyngyrz]

No, I think you *are* talking about pretty. The "conventions of the OSX interface" aren't nearly as important to me as they are to you. And a media player that is decently skinnable (mplayer comes to mind) can hopefully have any UI you want it to, and the first one it should have is the system standard one, but that in no way should preclude it also having any weird-assed interface that pleases the user.

The fact is, there is more than one way to be usable. I have no, and I mean zero, problem, using the GIMP under OSX because the interface is 100% functional. Running under X. In fact, most of the problems the GIMP has on the Mac are a consequence of OSX, for example, clicking on a window doesn't do what it should based on the UI element clicked upon, instead, it'll activate the window, which is just plain bad UI design, like the constant waste of space at the top of the display for the menu. Just because something is standard, doesn't mean it's good, and that's a fact.

Look at quicktime. It's standard, but it's crippled. Can't save movies (unless you pay extra) can't deal withy mpeg (unless you buy the add-on), yet it's a nice, standard Mac application. Comes to this, other software, even with a non-std interface, kicks quicktime's butt because it does the things you need it to do. And this is an Apple product! Kai's stuff was a problem not because it was non-standard, but because it was flipping inscrutible. Not just a little different, but other-planet, non-carbon-based-lifeform, no-rosetta-stone different.

Don't get me wrong — I love my Mac — but I don't love it because everything works the same. I love it because mostly, everything actually works. That's the real advantage it has over windows and linux, at least for me. That and not having to turn inverted backflips with a twist (usually in a CLI) to get an application installed (linux) or having to reboot three times if I so much as install a text file under windows (ok, obviously exaggerating, but youy get my drift.)

I reiterate, I don't care if Google earth uses OSX conventions. It's not important, in fact, it is trivial in the literal sense. What is important is that the Mac no longer lacks the functionality. Well, when we can run it, anyway... up until today, all I knew was from the Google page, which says "we're working on it" which isn't very enlightening or encouraging.

Finally, as a developer, I can tell you that the more of the core of an application is cross-platform, the easier it is to port, and the less it will depend upon, or otherwise utilize, a particular platform's standards. It'll probably look most like the platform is was designed upon, but even that isn't a given, especially if there are new UI ideas in the application. You can certainly go too far (Kai's!) but you can also not go far enough (GIMP) where the ported-to OS actually degrades the applications functionality, as happens with the brain-dead window activation approach that I've seen in so many Mac applications.

I well remember the first time I used Photoshop on the PC and found that the menus were acting quite Mac-like... they weren't PC menus at all. Adobe had gone and written their own menu handler so that the Mac menu code (I presume) would no have to be changed at all. The end result was a bit of disorientation (about ten seconds worth) for me, and then on I went, getting work done, in no way seriously inconvenienced. And why? Because it worked. Was it Windows standard UI? No. Did it matter? Nope. Not a bit. All it did was tell me I was working with a port.

So cheers to Google for just getting the job done. :)

Re:I really don't care what it looks like...

[JonathanBoyd]

The fact is, there is more than one way to be usable. I have no, and I mean zero, problem, using the GIMP under OSX because the interface is 100% functional.

But it's completely inconsistent with standard Mac GUI conventions.

In fact, most of the problems the GIMP has on the Mac are a consequence of OSX, for example, clicking on a window doesn't do what it should based on the UI element clicked upon, instead, it'll activate the window, which is just plain bad UI design

It'd be pretty annoyed if clicking on a window didn't activate it. If it's a toolbar that shouldn't be activated, then it should be a toolbar, not a window.

like the constant waste of space at the top of the display for the menu.

I prefer one easy to find menu bar to multiple menu bars in multiple windows, wasting a lot more space and taking more effort to reach.

Look at quicktime. It's standard, but it's crippled. Can't save movies (unless you pay extra) can't deal withy mpeg (unless you buy the add-on), yet it's a nice, standard Mac application. Comes to this, other software, even with a non-std interface, kicks quicktime's butt because it does the things you need it to do. And this is an Apple product!

How does the presence or lack of features make a difference to the interface?

Re:I really don't care what it looks like...

[fyngyrz]

But it's completely inconsistent with standard Mac GUI conventions.

And my exact point is that this affects its value not at all. The only thing that will affect its value here is if the user, that is, me, or you, decides to take an attitude that we're unwilling to use it because it is inconsistant. Me, I want to work on images, not worry about where the menu bar is, or isn't. That's simply a practical outlook. Consistancy is good — it means a (very little) less work for me to learn an application. But it is no barrier to use, to productivity, to quality.

It'd be pretty annoyed if clicking on a window didn't activate it. If it's a toolbar that shouldn't be activated, then it should be a toolbar, not a window.

You missed my point entirely. Say you're using Finder. So a Finder window is active. GIMP's been doing something and you were noodling around looking at other image filenames, say. GIMP pops up a dialog that says something like "Compress or save uncompressed?" with a "compress" button and a "don't compress" button. You point at the "compress" button, and you click on it. nothing happens. Why? because instead of clicking the button, OSX has activated the window. It should, indeed, activate the window but it should also have clicked that button. Now you have to click again, on the same button, to get the result you should have already had.

I prefer one easy to find menu bar to multiple menu bars in multiple windows, wasting a lot more space and taking more effort to reach.

Well, admitting up front that this is subject to various debates, let me point out the following issues:

• The menu at the top uses considerable vertical space, all the time, which is unusable for all applications. You can't get a window to cover the menu bar. At least, I can't in 10.3.9.
• Windows may, or may not, require a menu. For some (dialogs, for instance) a YES or NO or even simply OK is all the UI they need. This can be true of much more complex applications as well; if the developer is allowed to make that choice, of course.
• If a menu is embeddded in a window, say, application A, and there is no menu at the top of the screen, then application A may be dragged to the top of the screen, thus providing menu-on-top functionality if you like it.
• When menus are in the application window, and you are working in the application, you have less distance to go for any window that is smaller than the display and is not already located at the top.
• When only one menu can be in context, as is the case with OSX, it is possible (and I have had this happen many times) that you will accidentally click the desktop or another window on the way to the menu, and thereby lose the menu you wanted, and then have to go back and re-select the app that matches your menu (this happened a lot until I chucked the horrible one-button Apple mouse... darned thing was so heavy that when I moved it, then re-psoitioned it, it would self-click (mass of button descending would click the button) and I would lose the menu immediately. Incredibly aggravating. I tossed that mouse in the trash.) But the problem is in the menu system, the mouse just aggravated it.
• You refer to multiple menus "wasting a lot more space and taking more effort to reach." I would point out that when the menu is attached to a window, the window may descend beneath other windows in the Z-order so that regardless of how much space is dedicated to anything in that window, it is irrelevant to the application on top, because it gets to use the entire display: in-window menus are never in the way by their very nature. At the most, they obscure just about as much as an always-there top menu a'la OSX, with the added convenience that they stick with the application window as it is repositioned. That addresses

Re:I really don't care what it looks like...

[JonathanBoyd]

And my exact point is that this affects its value not at all. The only thing that will affect its value here is if the user, that is, me, or you, decides to take an attitude that we're unwilling to use it because it is inconsistant.

The problem with inconsistency is that programs do things you don't expect. If you spend 95% of your time working one way, but have to work a different way for the other 5%, it becomes pretty inconvenient. For instance, most of the time when I'm typing, I'm using my Mac and the cursor selects whatever line is in the middle of the text cursor. Part of my work, however, involves doing an announcement sheet for church every week in Corel Draw on Windows. For some unexplained reason, it selects whatever line is under the bottom third of the cursor. This drives me nuts because my instinct is select with the middle of the cursor and end up selecting the wrong line quite a bit of the time.

It also has a bizarre convention whereby if you drag select from somewhere on a line to the start of it, then make changes to the formatting of the line, it will also select the carriage return on the previous line and apply formatting to it. Consequently I often have to drag select to the 2nd letter of a line, then shift-left cursor select the first letter. After 14 weeks of use, I have come to loath this program because it does not follow the conventions that I'm accustomed to. Arguably, it's just plain bad design, rather than inconsistency, but I think the inconsistency is still a factor.

You missed my point entirely.

Indeed I did. I apologise. Thought you were talking about clicking a window in the foreground application. My bad.

Say you're using Finder. So a Finder window is active ... Now you have to click again, on the same button, to get the result you should have already had.

That is indeed annoying. Trying that out in other apps, however, clicking a button in a background application activates the button, so the problem would seem to lie with an inconsistency with the GIMP, rather than bad OS X GUI design. One more mark against inconsistency ;^)

The menu at the top uses considerable vertical space, all the time, which is unusable for all applications. You can't get a window to cover the menu bar. At least, I can't in 10.3.9.

Can't in 10.4.3 either, which I'm fairly happy about. Wouldn't want to lose sight of my menubar. It's fairly full. It's only a wee bit of vertical space, especially compared to the resolution of modern screens. Though if you're using multiple monitors, then you only need a menubar on one screen and can avoid them entirely on others, thereby saving space.

Windows may, or may not, require a menu. For some (dialogs, for instance) a YES or NO or even simply OK is all the UI they need. This can be true of much more complex applications as well; if the developer is allowed to make that choice, of course

True, but document windows all seem to have them, which irritates me greatly in Windows. Though the inconsistency in multi-document and single-document interfaces annoys me more. And the inefficient taskbar. And the way that opening multiple files belonging to one program sometimes loads the files into separate windows in one instance of the application, while launching several instances of the application in other cases. And not being able to open a bunch of files by double-clicking on a selected group. But I'm getting a bit off-subject here. I find Windows stressful. It just gets in the way so much.

If a menu is embeddded in a window, say, application A, and there is no menu at the top of the screen, then application A may be dragged to the top of the screen, thus providing menu-on-top functionality if you like it.

Only really works

Re:I really don't care what it looks like...

[fyngyrz]

The problem with inconsistency is that programs do things you don't expect. If you spend 95% of your time working one way, but have to work a different way for the other 5%, it becomes pretty inconvenient.

I see your point, though this doesn't affect me the way it does you.

That is indeed annoying. Trying that out in other apps, however, clicking a button in a background application activates the button, so the problem would seem to lie with an inconsistency with the GIMP, rather than bad OS X GUI design. One more mark against inconsistency ;^)

No, it's an OSX thing. I just opened finder, clicked into a directory so the window was well and truly focused and so on, then clicked a link in Safari which was visible below the finder window. Safari came to the top and the window became active, but the link was not followed. These are both about as native OSX app as you can get. This happens all over the place. If you watch for it, I think you'll find it soon enough. Anyway, this isn't so much a poster child for consistancy as it is for someone in the UI department needing a bit of a beating. :)

Only true if only window is visible. If multiple windows are visible, as would be required in the GIMP, then they're all using up screen space.

No. Because the window that has the focus is on top, so it can never be obscured by any other window, GIMP's or otherwise. That's why window-based menus can never get in each other's way.

But ti takes longer to get them because they're smaller targets. If I want to get to the top of the screen, I can be there in an instant from anymore. So I definitely disagree, though in an amicable fashion, as befits the tone of this debate :)

Huh. Well, I'll buy your argument if you'll tell me how you get to the top of the screen in an instant. I can't, as far as I know -- it's further to roll the mouse to the top than it is to the top of a window, barring the single exception where the window is at the top anyway (in which case it takes just as long.) For me, I have no trouble hitting a UI element, and there's no particular speed difference. I've been mousing just about since there were mice and GUIs, though, and that could be a factor. I paint and draw with a mouse, too, though to be fair, I usually have a considerably better interface to work with than is available on the Mac for image processing and effects work. Not only faster, but more efficient and more flexible, because it naturally uses more of what a mouse can do. I am very, very precise with a mouse, so in-window menus are just no problem at all. So -- how do you get right to the top of the display with less moves than it takes to get to the top of a window that is, for instance, showing its title bar at the bottom third of the display?

I'm not sure how fair a comparison it is, given that the features in Quicktime are fairly rich, if you do pay for them. It would be like criticising shareware for not being feature-full if you didn't register it.

Well, I really wasn't trying to go there -- I was trying to say that given two programs that addressed any particular area, I would go for the one that gave me the most features, tools, capabilities, not the one that was UI compliant, that's all. Quicktime was probably a poor example, especially since I wasn't specific about what other software I had in mind. Again, my apologies.

Anyway, thanks for a pleasant discussion.

Likewise. :-)

Re:I really don't care what it looks like...

[dave1212]

Inconsistency severely affects an app's usability, since things don't work as you expect.

This eventually leads to bad reviews, negative word-of-mouth, and less sales. I would say inconsistency affects an app's usability a great deal.

Myself, I would choose interface compliance over feature bloat.

Re:I really don't care what it looks like...

[Anonymous Coward]

Anyone who would choose features over consistency is missing one of the main points of the Mac OS in the first place. However, you both seem to be missing the bigger picture.

Re:I really don't care what it looks like...

[JonathanBoyd]

No, it's an OSX thing. I just opened finder, clicked into a directory so the window was well and truly focused and so on, then clicked a link in Safari which was visible below the finder window. Safari came to the top and the window became active, but the link was not followed. These are both about as native OSX app as you can get. This happens all over the place. If you watch for it, I think you'll find it soon enough. Anyway, this isn't so much a poster child for consistancy as it is for someone in the UI department needing a bit of a beating. :)

On the other hand, if you bring up the print dialogue, switch to another app so Safari goes to the background, then click on print, or cancel, or whatever, the button will activate without further clicks. Same goes for the bookmark bar. It just doesn't count links on the page as buttons, which I approve of.

Having aid that, are you aware that cmd-clicking on background UI elements allows you to trigger them without switching app focus? If I cmd-click on a link in Safari, it will go and load the link in a new tab without switching focus. I would use this every once in a while to scroll a background window or click a background button when I want to keep working in the current front app.

No. Because the window that has the focus is on top, so it can never be obscured by any other window, GIMP's or otherwise. That's why window-based menus can never get in each other's way.

But the point isn't about menus being obscured - after all, you can't obscure the OS X menu bar. It was about wastage of space and if you have more than one window on screen, then each one with a menu will waste space. e.g. working in the GIMP requires you to have several windows open, IIRC, each with a menubar.

Huh. Well, I'll buy your argument if you'll tell me how you get to the top of the screen in an instant. I can't, as far as I know -- it's further to roll the mouse to the top than it is to the top of a window, barring the single exception where the window is at the top anyway (in which case it takes just as long.)

One quick finger or hand movement moves the cursor straight to the top of the screen. Thanks to the acceleration present, this takes very little time. Aiming for a particular spot on screen, however, usually means two movements - one relatively quick one to the right area, then a slower one to the precise area, occasionally because I've overshot.

I've been mousing just about since there were mice and GUIs, though, and that could be a factor.

I've been mousing since the days of the Atari STE, which is long enough to be fairly competent. Besides, if that were a factor, it would imply that you need years of experience to use the GUI you prefer effectively, making it the worst choice for new-comers to a computer, or for irregular users.

Re:I really don't care what it looks like...

[Smurf]

Huh. Well, I'll buy your argument if you'll tell me how you get to the top of the screen in an instant. I can't, as far as I know -- it's further to roll the mouse to the top than it is to the top of a window, barring the single exception where the window is at the top anyway (in which case it takes just as long.) [. . .] So -- how do you get right to the top of the display with less moves than it takes to get to the top of a window that is, for instance, showing its title bar at the bottom third of the display?

Allow me to chime in and rehash a post that I made a few weeks ago:

Hmmm.... you need to increase the acceleration of your mouse. Whenever I've used a Mac with a mouse, I have only needed to jerk the mouse quite less than three inches to go from one corner of the screen to the other on 30" monitors at 2560x1600 (and much less in smaller monitors). Right now I can't make that test because I only have a Powerbook and a Windows PC with a PS/2 mouse in front of me. But, for what it's worth:

On the Powerbook, I can go from one corner to the other (1280x854) with only one swipe through the trackpad. The speed is set one tick faster than the middle setting. There are four more ticks to the right, and if I set it at the maximum, I can cover the diagonal by swiping over half the trackpad. But that's way too fast for me. (Note that there is no acceleration control for the trackpad).

On the Windows PC (an old Dell P4), at 1600x1200, I can travel the diagonal by jerking the mouse once around two inches. I have never touched the mouse settings so far: the speed is in the middle tick, the acceleration is in... surprise: low.

Let me set it to High (there are None, Low, Medium, and High settings). Ok, now I can cover the 1600x1200 diagonal with a 1 inch jerk (again, way to fast for me).

I never change the mouse settings for computers that aren't mine, but my experiences have been consistent with the above data, both with Macs and PCs. My guess is that you simply move the mouse too slowly. There is no shame on that, simply adjust the settings so that they better suit you.

Now, returning to your point, fyngyrz, since you appear to in the graphics industry maybe increasing the speed or acceleration of the mouse is not a good option (I guess). (On the other hand, I'm quite sure that if you use the computer to draw you are much better off with a digitizing tablet). But for the vast majority of users, crossing through the screen could be a swift wrist twist away.

(By the way, thanks to you and to JonathanBoyd for having a civil and interesting discussion, although at the end it seems that you (or we) only agreed to disagree.)

Re:I really don't care what it looks like...

[muchmusic]

following a few simple interface guidelines would suffice - it doesn't have to be gaudy like the Kai or flashy like first person shooter game menus - this is a crazy mix of interfaces from 10.2, 10.3 and Windows XP - style buttons. This isn't anywhere near ready for primetime usage unless it's been camoflauged to throw sneaks off the scent.

Re:I really don't care what it looks like...

[good soldier svejk]

Huh. Well, I'll buy your argument if you'll tell me how you get to the top of the screen in an instant. I can't, as far as I know -- it's further to roll the mouse to the top than it is to the top of a window, barring the single exception where the window is at the top anyway (in which case it takes just as long.) [. . .] So -- how do you get right to the top of the display with less moves than it takes to get to the top of a window that is, for instance, showing its title bar at the bottom third of the display?

The answer is Fitt's Law: The time to acquire a target is a function of the distance to and size of the target. The top of display menu bar is infinitely tall. You can't overshoot it. No matter how fast and far you move your mouse, the curser stops on the menu. The only improvement would be to place the target in the corner of the screen where you can't overshoot it lateraly either. OpenStep used to do this.

When you maximize a Windows window the menu targets do not extend all the way to the top of the screen, so they do not behave like Mac menus, are not infinitely tall and are just as hard to acuire as they are in any other window position.

One of my most hated Windows features used to be the way minimized windows behaved in the taskbar. Their target did not extend all the way to the bottom of the screen! Hence you could overshoot them. This was an unforgivable waste of valuable edge real estate. Thankfully they have fixed this.

Re:I really don't care what it looks like...

[catdriver]

Anyway, thanks for a pleasant discussion.

Likewise. :-)

Wait a second... this is Slashdot! You guys can't have a civilized discussion where you respect each others' differences! We won't stand for it!

google earth beta download

[Anonymous Coward]

well you dont have to wait for it http://mypersonalgetaway.com/

Re:google earth beta download

[aclarke]

Very very cool. I have it running on my computer right now. Runs great on my 1.67 powerbook. AWESOME, thanks!

I don't know...

[uradu]

It looks about as cheesy as the rest of Mac OS X, past or present. Candy buttons are candy buttons, regardless of degree of shine.

One other Google port that would be nice.

[WhiteBandit]

One other Google port that I would love to see for OS X would be Picasa. Such a great program for organizing and keeping track of your photos (much better than iPhoto in my opinion).

Re:One other Google port that would be nice.

[Anonymous Coward]

One of the first things I do on any new mac is to delete iPhoto. It's a piece of shit.

why did they choose windows first, instead...

[josepha48]

.. of a solution that was cross platform, like Java or python or perl?

It boggles my mind!

Re:why did they choose windows first, instead...

[discstickers]

Because they bought an existing Windows product?

Re:why did they choose windows first, instead...

[shodson]

Uh, probably because they wanted to reach an audience of 90+% of the computing planet instead of trying to adhere to some technology religious standard.

Re:why did they choose windows first, instead...

[dr.badass]

why did they choose windows first, instead...of a solution that was cross platform, like Java or python or perl?

Google didn't develop it from scratch. They bought up a company called Keyhole. Google Earth is basically a free version of Keyhole's $400 product, which is now "Google Earth Pro".

Re:why did they choose windows first, instead...

[outZider]

Because they wanted it to be fast? Cripes, the last thing I want running on my PC or my Mac is some bloated Java/Python/Perl app. :P

Re:why did they choose windows first, instead...

[Anonymous Coward]

You are a fucking moron.

And you need a diaper change.

10.2?

[antdude]

I wonder if that means it will work under Mac OS X 10.2? I am still running 10.2.8 on my old PowerBook G4 (1 Ghz; 512 MB of RAM). I am just cheap and lazy to upgrade. :)

torrent please?

[jasongetsdown]

where can I get it? I don't see any useful links in the article or on the google earth page.

Re:torrent please?

[nuggetman]

check digg

For similar functionality with more focus on sci

[Ilgaz]

There is Earthbrowser on OS X (and win32) for ages. I don't think it is same with Google earth but it is much more educational and fun program.

They now added satellite photos feature so makes it more cool.

It is installed on many schools,universities but doesn't make it "boring". Especially on hurricane season. ;)

Check yourself

http://www.earthbrowser.com/

They bought it.

[Grincho]

Google didn't write it; they bought it as a Windows-only program from somebody else.

Very interesting

[Anonymous Coward]

Very cool! It doesn't have the resolution of Google Earth, but it is much more interesting. Once you see your house and a few other things in GE, what is left to do???

Re:For similar functionality with more focus on sc

[tricorn]

Another interesting program is Celestia. I haven't tried any, but there are apparently lots of available high-resolution images available for various parts of the Earth as well as higher-resolution images for some of the other planets. The controls for moving around aren't intuitive, but it is a lot of fun to go zooming around the galaxy (and even some nearby galaxies, rendered as grayish-looking 3-d blobs).

Does it require 10.4?

[Glenstorm]

I tried to use it on a PB running 10.3.9 and it never appeared in the dock after double clicking. . . Usual behavior for those apps that require 10.4.

Re:Does it require 10.4?

[swissfondue]

Yes. But it does work well on my G4 1ghz.

Here is another download link: rapidshare

why use this when you got local.live.com?

[pissu_man]

Check out Microsoft's come back.

download

[tezbobobo]

SHIT! I waited half a day for someone to list the download site - and noone did!

If you want to download it, here it is.

Google Earth for Mac

[Anonymous Coward]

I downloaded Google Earth (Beta) 3.1.0171.0 build 12/1/05 (from MacUpdate) and it works well. Blazingly fast, as compared to a PC in medium resolution mode (512 x 512). Still a beta though, no printing, email, web etc. but it really flys!

live.com anyone?

[pissu_man]

Check Microsoft's answer to Google Earth. The brid's eye view is amazing. It will pose a big challenge to Google.

Re:live.com anyone?

[aristotle-dude]

This story is about the OS X version of Google Earth. MSFT's answer does not work on Safari which is the dominant browser on OS X. Maybe you are confusing Google earth with Google Maps? In any event, I cannot see how decades old aerial photography can compare with recently updated (within last two months) satellite imagery. If you were to try Google Earth, you would find that it sports higher resolution imagines than their google maps service.

flash based google earth

[Anonymous Coward]

This website has google earth as well as msn virtual earth accessable via web browser, so it is compatible with mac, linux, what ever has a flash enabled browser

http://www.flashearth.com/

a.b.m.a - Usenet rules.

[Anonymous Coward]

alt.binaries.mac.applications

NASA WorldWind and alike on MacOS X

[Lord Satri]

This is indeed really great news. Let's not forget the open NASA WorldWind project also has Java/OpenGL versions in development for MacOS X and Linux and that WorldWind itself has been forked into Punt.

If you're serious about geospatial, you might be interested in joining us :-)

see in in action at the apple store...

[Anonymous Coward]

I was downtown at the Apple Store on Michigan Ave in Chicago last night and they had Google Earth running on one of their large Apple Studio Displays...pretty darn impressive looking.

get it

[Anonymous Coward]

get it

Re:get it

[Anonymous Coward]

The links dead, Jim.

iPhoto

[Anonymous Coward]

With a good graphics card, iPhoto kicks ass. I have 21,329 photos, which I can quickly scrub in thumbnail format.

Tags make everything easy to find, although one must be meticulous about tagging imported photos.

Best: seamless .mac integration means my wife posts pics to the web - something I simply would never get around to doing.

Viva iPhoto.

What took so long?

[bjb]

If the application was written in QT, why didn't we see this sooner? Isn't that the whole idea of using QT - to get a cross platform set of GUI components so that you only really need to worry about the program logic underneath?

I guess its possible that if the Windows version is using DirectX and the "other" versions are using OpenGL, that could be the cause for delay. However, I think QT might abstract the GL library anyway?

Well, its about time anyway.

I already have it.

[Anonymous Coward]

I already have Google Earth on my powerbook G4 running Tiger. Downloaded it last week, probably shouldn't say where though. I guess all I'm saying is... nyah nyah. heh :) No really, it works fine, and I'm sure they will release a better looking one after getting all the kinks worked out in the code. It's only crashed once - the first time I ran it.