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

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.

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: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