Mac OS X Snow Leopard Discussion

[Sciatic]

Another shot from Macrumors of the new menus. I think it looks garish when not in HUD modes like Dock Expos?.

That looks very much like the jumplists in Windows 7.

[The_Decryptor Veteran]

That functionality has been there since the OS X beta.

Unless you mean appearance wise, in which case there's even less similarities.

[Phantom Helix]

Oh cool, the period's already started.

Well, that's helpful, thanks for the links!

No Problem, im not exactly sure though why it goes all the way to december, Apple has a history of updating the installed Version of OS X very quickly, this iMac I bought two months ago had 10.5.6 pre-installed and anything you buy now surely has 10.5.7, so you would think that by September's release all new purchased Mac's would already have 10.6??

That looks very much like the jumplists in Windows 7.

Yup been there for some time, here a snap of my 10.5.7 lol only thing they added was the "options"

[PyX]

Cocoa (while a great framework) doesn't magically make an app look or perform better, there's no user facing differences really (Case in point, people keep saying Firefox needs to use Cocoa instead of Carbon, it already does)

So far, here's what I noticed :

Applications made in Carbon that are really seriously optimized like iTunes and the Finder are still a little slow (yes, I feel like iTunes doesn't use its full potential on OS X)

Applications made in Cocoa that are really seriously optimized are automatically faster and snappier. Take the new Finder in Snow Leopard as an example. Or maybe it's the underlying code that sped up a few things, but I think making the Finder a Cocoa application really did change a few things...

Firefox is clearly not optimized at all, and same goes for Office.

That looks very much like the jumplists in Windows 7.

I had all these options back in Tiger when right clicking on an icon, I don't know about the previous versions of OS X.

Yeah the only thing is, they regrouped 2 options in the "Options" submenu.

[Phantom Helix]

Applications made in Cocoa that are really seriously optimized are automatically faster and snappier. Take the new Finder in Snow Leopard as an example. Or maybe it's the underlying code that sped up a few things, but I think making the Finder a Cocoa application really did change a few things...

To be fair, the finder in SL is also 64-bit, as-well the refinements to OS itself adds to all applications being faster.

For a good comparison you would have to run that version of finder in 32-bit mode in 10.5, which you can't because it will not run on the 10.5 architecture.

and when i first installed, 10a380 the speediness of the OS was amazing, when i switched the kernel to run in 64-bit mode, HOLY cow!!!, it was like the same difference between 10.5.7 and SL.

So in that context SL gets a large portion of the credit for your example.

[giga Veteran]

Finder in 10.6 is also Grand Central Dispatch optimized, in addition to 64-bit.

[suspiria]

http://arstechnica.com/apple/news/2009/07/...sual-tweaks.ars

What's with that weird slider to the lower right? Looks like a blue "unsaved" window close button. I hope it's just temporary because it's ugly as sin.

[.Neo]

Cocoa (while a great framework) doesn't magically make an app look or perform better, there's no user facing differences really

Can't say I fully agree with that. The Finder, QuickTime, iTunes etc. all have/had weird interface quirks compared to Cocoa applications. Technically it might be possible to create a Carbon application with a 100% picture perfect Aqua interface, however to this day I haven't seen one.

I also find it striking that Cocoa applications always seem to feature more and more advanced animations than their Carbon counterparts. Perhaps Carbon applications can't use the Core Animation framework?

That looks very much like the jumplists in Windows 7.

Mac OS X has had these menus since 2001, the only thing that changed are the graphics and they grouped some things together under "options".

Edited July 11, 2009 by .Neo

[Quillz]

I also find it striking that Cocoa applications always seem to feature more and more advanced animations than their Carbon counterparts. Perhaps Carbon applications can't use the Core Animation framework?

I've definitely noticed this with Snow Leopard's Finder. Moving things around, highlighting objects, etc. all have very subtle "fade-in" effects now. In Leopard's Finder, the animations (or lack of them) was jerky.

Why does Apple still build applications like iTunes in Carbon? Shouldn't they be in Cocoa?

[the evn show]

Technically it might be possible to create a Carbon application with a 100% picture perfect Aqua interface, however to this day I haven't seen one.

By definition they all have Aqua interfaces - that's the name given to the over-all appearance of Mac OS X. Brushed metal? That was aqua. Ugly pinestripes? Aqua too. Modern unified title-bar? Still aqua. A few minor animations are specified (ie: print sheets) but for the most part that's not even defined.

The idea that something like Finder, iMovie, or Safari have a "less aqua" or "more aqua" interface than Keychain access or Final Cut Pro is a misunderstanding of what Aqua is.

I also find it striking that Cocoa applications always seem to feature more and more advanced animations than their Carbon counterparts. Perhaps Carbon applications can't use the Core Animation framework?

There are some things that are difficult when you use carbon that are trivial when you use Cocoa but for the most part it's not going to be apparent to an end user.

wrt. Core Animation: it's a bit of an ugly situation but it is possible to use it from within a Carbon application by using HICocoaView to embed an NSView derived control into a Carbon view. As with most things in programming: what's possible is almost universal: you can make an Application with the flash of Panic's Candybar using .Net or WinAPI just as you could with Carbon or Cocoa.

Most of the time animation isn't critical to an application so it's importance is lower than things like "not blowing up" or "doing whatever the heck it is this program is supposed to do." Cocoa makes animations like you see throughout Mac OS X pretty easy - often just a couple of lines of code (which makes them easy to disable for debugging too). Carbon and WinAPI require the developer to do a lot more of the low-level leg work for that sort of thing so it becomes more costly to implement them. If you can add animation to your UI in 15 minutes then it's a no brainer. If it takes 3-4 hours you might do it for version 2, and if it takes a couple of days it might be the sort of thing that gets dropped entirely.

Based on a quick browse over otool -L and a check in Instruments) both iTunes and Finder are handling things like Coverflow the same way - it's not a matter of Core Animation being "cocoa only" (or even applications being forced to use only Cocoa or only Carbon: you can mix and match as you please).

Why does Apple still build applications like iTunes in Carbon? Shouldn't they be in Cocoa?

They're recycling code for the Windows version, re-writing isn't trivial, and until recently Carbon was considered a first-class Companion to Cocoa.

[Quillz]

Anyone notice the latest build is having a lot of issue with drag and drop support on the Dock? Normally I can drag applications straight from a disk image into the Applications stack, but now I can't; I have to physically open a new Finder window. Sometimes apps I drag from the Applications stack onto the Dock won't stick.

I don't recall these bugs being in previous builds.

[.Neo]

Yeap, noticed it as well. I tried several times to delete a folder by dragging it from the Download stack to the Trash and nothing would happen. Eventually I managed to delete it, but only after several attempts.

By definition they all have Aqua interfaces - that's the name given to the over-all appearance of Mac OS X. Brushed metal? That was aqua. Ugly pinestripes? Aqua too. Modern unified title-bar? Still aqua.

I'm aware of that. Anyway that wasn't exactly what I meant: For some reason interface behaviour and in some cases even appearance between Cocoa and Carbon applications tend to differ.

They're recycling code for the Windows version, re-writing isn't trivial, and until recently Carbon was considered a first-class Companion to Cocoa.

If they want to release a fully 64-bit iTunes, Apple more or less forced themselves to write it in Cocoa right?

[Phantom Helix]

Anyone notice the latest build is having a lot of issue with drag and drop support on the Dock? Normally I can drag applications straight from a disk image into the Applications stack, but now I can't; I have to physically open a new Finder window. Sometimes apps I drag from the Applications stack onto the Dock won't stick.

I don't recall these bugs being in previous builds.

You are correct sir, i also tried dragging an app from the stack to the dock and it would not stick

drilling down in folders from grid view is also spotty

[.Neo]

Something I still miss from the Leopard betas is the ability to create an applications stack in the applications side of the Dock by simply dragging more than one application to the Dock.

[Quillz]

You are correct sir, i also tried dragging an app from the stack to the dock and it would not stick

drilling down in folders from grid view is also spotty

Good, so it's not just me. I assume a future build will be much more stable, especially since the previous build worked fine in this regard.

Something I still miss from the Leopard betas is the ability to create an applications stack in the applications side of the Dock by simply dragging more than one application to the Dock.

Same here. The feature worked well from what I can remember, so I do wonder why Apple removed it. Maybe we'll get lucky and see it restored for Snow Leopard.

[the evn show]

I'm aware of that. Anyway that wasn't exactly what I meant: For some reason interface behaviour and in some cases even appearance between Cocoa and Carbon applications tend to differ.

It also differs between Cocoa applications - there isn't sufficient evidence to blame it on the API chosen as a matter of course.

If they want to release a fully 64-bit iTunes, Apple more or less forced themselves to write it in Cocoa right

Without worrying to much about the details: that's true enough. There are some hoops you can jump through to keep a Carbon core with a Cocoa UI or 32-bit Carbon front end (which is how applications like Photoshop CS5 will work, and how you had to build 64-bit Applications in earlier versions of OS X)

The question is: "What would you gain by to writing fully 64-bit version of iTunes keeping in mind the need to support earlier versions of OS X and Windows?"

[Phantom Helix]

The question is: "What would you gain by to writing fully 64-bit version of iTunes keeping in mind the need to support earlier versions of OS X and Windows?"

Compatibility would be easy enough to maintain with a version stripped of 64bit and a full SL 64bit version, a lot like they released different packages for OS X and OS9.

It apears they don't have a problem with seperate versions, especially when looking at Quicktime X, the Windows Version may get the new UI, however I doubt it will get much changes under the hood, not compared to the Mac version.

Since Apple has now with SL, pushed into the fully 64bit arena, 64bit Versions of Windows becoming more mainstream and necessary on systems with Large amounts of ram, Why wouldn't Apple create a 64bit iTunes?

My iTunes library file is nearing 30mb, the Genius File is 95mb, the library.xml is 12mb and the Music library.xml is 11mb, i would think 64bit iTunes would handle those files much better even without all the other tech of SL.

If you ask me iTunes will be 64bit by v 9.0 if not before

[the evn show]

Compatibility would be easy enough to maintain with a version stripped of 64bit and a full SL 64bit version, a lot like they released different packages for OS X and OS9.

If they plan to continue supporting 10.5 with iTunes then they'll have to maintain a 32-bit front end. The question then becomes: What do you gain using a 64-bit framework for the front end.

So long as you're supporting 10.5 it's more work than it's worth because it requires maintaining two independent code bases for no real gain. Given that iTunes 8 runs on G3s running Tiger I don't see Apple dropping the axe on 10.5 systems any time soon and that makes a 64-bit Cocoa front end pretty much pointless.

It apears they don't have a problem with seperate versions, especially when looking at Quicktime X, the Windows Version may get the new UI, however I doubt it will get much changes under the hood, not compared to the Mac version.

If anything the reverse is likely to be true. The value of Quicktime is as a media playback API - the player portion is the most visible but least interesting part of that. Quicktime Player is to Quicktime as Safari is to Webkit: the interesting parts don't have a UI.

Since Apple has now with SL, pushed into the fully 64bit arena, 64bit Versions of Windows becoming more mainstream and necessary on systems with Large amounts of ram, Why wouldn't Apple create a 64bit iTunes?

The reason you wouldn't is because:

• There's no tangible benefit. iTunes won't be faster, it isn't memory limited, etc.
  
• It breaks compatibility with earlier versions of the OS or requires two branches to be maintained.
  
• It increases the burden of testing, validation, debugging, etc.
  
• It may depend on licensed code that is not available 64-bit (see: DVD Player which remains 32-bit in 10.6)
  
• Compatibility with Windows remains a primary goal - Objective C (the recommended language for use with Cocoa) is less than ideal.
  

My iTunes library file is nearing 30mb, the Genius File is 95mb, the library.xml is 12mb and the Music library.xml is 11mb, i would think 64bit iTunes would handle those files much better even without all the other tech of SL.

No, you need to be dealing with multiple gigabyte files before you see significant improvements. But even if you had libraries that large the benefit wouldn't be in using 64-bit functions to parse them and that is completely decoupled from the UI. iTunes isn't the sort of program that benefits from being 64-bit just like Address book and Text-edit aren't.

If you ask me iTunes will be 64bit by v 9.0 if not before

Want to bet on it? I'd put $50 (as a donation to a charity or Neowin in the Winners name) on the opposite: iTunes retains a 32-bit UI in the next major release.

I think we'll see it sooner rather than later so we won't have to wait too long to find out.

Edited July 12, 2009 by evn.

[PyX]

I think they will create multiple versions of iTunes : 2 for Windows and 2 for OS X.

1 for 10.6 and later and the 2nd one for 10.5 and sooner. :)

That's a lot of work, but if you still want PowerPC users to have these latest iPods and everything? You don't have the choice.

[Quillz]

That's a lot of work, but if you still want PowerPC users to have these latest iPods and everything? You don't have the choice.

Actually, Apple doesn't want the PowerPC users to have the latest iPods and everything. They want them to replace their machines with newer ones that have Intel chips.

[.Neo]

It also differs between Cocoa applications - there isn't sufficient evidence to blame it on the API chosen as a matter of course.

Maybe you're right.

The question is: "What would you gain by to writing fully 64-bit version of iTunes keeping in mind the need to support earlier versions of OS X and Windows?"

Can't one ask that same question when it comes the majority of applications that ship with Mac OS X?

Edited July 12, 2009 by .Neo

[.Neo]

PS I don't really care what they do with iTunes as long as they give the application some kind of overhaul. The application is amazingly slow compared to most other applications that ship with my Mac Pro. There is a night and day difference is scroll speed between iPhoto and iTunes for example.

[the evn show]

Can't one ask that same question when it comes the majority of applications that ship with Mac OS X?

No. The majority of applications that are bundled with OS X (like Keychain, Address Book, Mail, etc) aren't required to run on earlier versions of Mac OS X or Windows.

[.Neo]

What does one really gain by having a 64-bit version of Address Book?

[the evn show]

What does one really gain by having a 64-bit version of Address Book?

Not a damn thing really, especially when you keep in mind that they ship a 32-bit version in 10.6.

They also didn't lose anything because Address book has none of the computability requirements that iTunes does, nor did it have a sizeable Carbon dependency.