Mac OS X Lion Discussion

By giga
in Apple (macOS)

 Share

Recommended Posts

Grand Master

Quillz

Posted
Posted

I was actually thinking we might have had a new build by now. I'm hoping for another one in early April.

Interestingly enough, though, I just last night finally got an e-mail response regarding the bug reports I submitted at least three weeks ago.

Mentor

OOOOOOOO

Posted
Posted

Apparently we may be seeing a GM release of some kind soon ...

http://techcrunch.com/2011/03/25/os-x-lion-gm/

Specifically, Apple is gearing up to deploy an OS X Lion update to developers that they may be classifying as the ?GM1? release, we?ve heard. ?GM? or ?Golden Master? is a title reserved for software that is complete. But from what we?ve heard, this is only the initial Golden Master candidate. In other words, don?t get too excited just yet.
Grand Master

Quillz

Posted
Posted

They actually answer you if you submit bugs? That never happened to me :p

I, for one, am not surprised we haven?t seen any build yet. After the first public build, they got a lot of feed-back, thus have a lot to fix. I?m hoping for a new build in April...

It was just a generic canned response. They said all the bugs I submitted had been submitted before so they already knew about them. But that's a good thing, it seems to imply the next build made public should take care of them.

Apparently we may be seeing a GM release of some kind soon ...

http://techcrunch.com/2011/03/25/os-x-lion-gm/

You know, I don't recall Leopard or Snow Leopard having anything other than the GM called a GM#. Interesting, I'd imagine it's Apple's terminology for a RC.

Grand Master

PGHammer

Posted
Posted

What do you mean, you don?t what? You don?t have an account in the Mac App Store? You don?t have a credit card? You don?t link your credit card number to your account? You don?t download anything from the store?

Same. This is the first build that got in the hands of thousands of people. They will get a bunch of comments, bug reports, complaints, and everything.

On one side, they need to stick to their roadmap, and on another side they need to sort out all the feed-back, then they need to address the major problems reported. Finally, they need to compile and test everything that has been added to see if it actually works better.

Lion?s developer build was released like yesterday. They need to breathe for a bit and maybe in April we?ll get another build.

Accounts at the MAS/iTunes/ADC are *identical* - you can use the same credentials for all three. And you don't need a credit card (for the simple reason that there are items in all three places that are free) - I have an account - with no credit card - that I use for all three.

NovaBench (benchmarking utility) is among the free Leo/SL/Lion-ready MAS apps.

Grand Master

.Neo

Posted
Posted

After using my iPad 2 for a day I'm completely blown away by the iOS version of iTunes. It's so incredibly smooth: Scrolling without so much as a hiccup, advanced animations everywhere and overall the interface is just amazing. The biggest issues we have with the application are non-existent there, it's iTunes done right.

If anything Apple should rewrite iTunes for Mac OS X in its image.

Grand Master

Jan Veteran

Posted
  • Veteran
Posted

After using my iPad 2 for a day I'm completely blown away by the iOS version of iTunes. It's so incredibly smooth: Scrolling without so much as a hiccup, advanced animations everywhere and overall the interface is just amazing. The biggest issues we have with the application are non-existent there, it's iTunes done right.

If anything Apple should rewrite iTunes for Mac OS X in its image.

Yeah iTunes is pretty amazing on my iPad 2 as well, the iPad 2 is by far the best tablet out there.

Grand Master

Quillz

Posted
Posted

Is the developer preview stable enough to use as a primary operating system? I'm just a user; I browse the web, listen to itunes, chat via adium.

I didn't have any major issues with it, but I still wouldn't recommend using it day-to-day. Although if you like using beta software, I'd certainly suggest you try it out.

Grand Master

PyX

Posted
Posted

Well Adium for one didn't really work that well for me on Mac OS X Lion.

Because it worked well on Snow Leopard? :laugh:

I get a few crashes here and there and a buuuuuuunch of bugs.

About iTunes 11, it WILL happen in September, and I?m ready to bet my right hand that it?ll be rewritten completely in Cocoa/Objective-C/64-bit support, feature a new optimized Windows 7 interface that fits Aero as much as Safari does, remember what song you were playing last and where you where in your library after closing it (well this last one isn?t hard to predict, it?s one of Lion?s key features after all)

Otherwise they?re getting really annoying with their useless iTunes features that add bloat everywhere.

Grand Master

the evn show

Posted
Posted

What exactly is it people expect to gain from iTunes re-written in Cocoa?

Here's the current list of stuff iTunes links against:

It seems to me what people want is an overhaul of the UI and possibly the compartmentalization of some features. I don't think we're going to get them for purely business reasons: having the iTunes store (etc) built into iTunes forces it in your face much better than having it as a separate application does. And it's not like Apple couldn't build a complete UI-abortion with Cocoa alone.

	@executable_path/../Frameworks/iPodUpdater.framework/Versions/A/iPodUpdater (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
	/System/Library/Frameworks/AddressBook.framework/Versions/A/AddressBook (compatibility version 1.0.0, current version 883.0.0)
	/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 38.0.0)
	/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 152.0.0)
	/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 44.0.0)
	/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 293.5.0)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime (compatibility version 1.0.0, current version 1742.0.0)
	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 37594.0.0)
	/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.6.2)
	/System/Library/PrivateFrameworks/iPod.framework/Versions/A/iPod (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
	/System/Library/Frameworks/QTKit.framework/Versions/A/QTKit (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 751.29.0)
	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 15.0.0)
	/System/Library/Frameworks/WebKit.framework/Versions/A/WebKit (compatibility version 1.0.0, current version 533.16.0)
	/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/JavaScriptCore.framework/Versions/A/JavaScriptCore (compatibility version 1.0.0, current version 533.13.0)
	/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 40.0.0)
	/System/Library/Frameworks/Quartz.framework/Versions/A/Quartz (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/ImageKit.framework/Versions/A/ImageKit (compatibility version 1.0.0, current version 1.0.0)
	@loader_path/libgnsdk_musicid.1.8.2.dylib (compatibility version 1.8.2, current version 1.8.2)
	@loader_path/libgnsdk_sdkmanager.1.8.2.dylib (compatibility version 1.8.2, current version 1.8.2)
	@loader_path/libgnsdk_submit.1.8.2.dylib (compatibility version 1.8.2, current version 1.8.2)
	@loader_path/libgnsdk_dsp.1.8.2.dylib (compatibility version 1.8.2, current version 1.8.2)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 103.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.29.0)
	/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.6.1)
	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1038.35.0)

Note that iTunes is already using Cocoa (and CoreAudio/video, appkit, webkit, etc) and that everyone's favorite examples of Cocoa applications link against similar libraries (ie: safari links against Carbon, libgcc/libogjc/etc, securityframework, etc) -- Why the concerns about the framework when what really matters is the user interface and performance? For all I care they could write the damn thing with QT and Java if it'd worked better than what we have now.

Mentor

DeadEndAccount

Posted
Posted
What exactly is it people expect to gain from iTunes re-written in Cocoa?

Here's the current list of stuff iTunes links against:

It seems to me what people want is an overhaul of the UI and possibly the compartmentalization of some features. I don't think we're going to get them for purely business reasons: having the iTunes store (etc) built into iTunes forces it in your face much better than having it as a separate application does. And it's not like Apple couldn't build a complete UI-abortion with Cocoa alone.

Note that iTunes is already using Cocoa (and CoreAudio/video, appkit, webkit, etc) and that everyone's favorite examples of Cocoa applications link against similar libraries (ie: safari links against Carbon, libgcc/libogjc/etc, securityframework, etc) -- Why the concerns about the framework when what really matters is the user interface and performance? For all I care they could write the damn thing with QT and Java if it'd worked better than what we have now.

There is more to the 'move to Cocoa than the obvious; I'd say there will be a move to possibly AV Foundation or at least QtKit will be sit ontop of AV Foundation which will be a bare bones basic framework. Cocoa allows 64bitness which includes better ASLR support, access to more registers, gaining benefits of GDC, compiler better optimisations etc.

I'd love to see changes happen but it all comes back to Apple and whether they consider its worth their while in the long run.

Grand Master

.Neo

Posted
Posted

What exactly is it people expect to gain from iTunes re-written in Cocoa?

Here's the current list of stuff iTunes links against:

It seems to me what people want is an overhaul of the UI and possibly the compartmentalization of some features. I don't think we're going to get them for purely business reasons: having the iTunes store (etc) built into iTunes forces it in your face much better than having it as a separate application does. And it's not like Apple couldn't build a complete UI-abortion with Cocoa alone.

Note that iTunes is already using Cocoa (and CoreAudio/video, appkit, webkit, etc) and that everyone's favorite examples of Cocoa applications link against similar libraries (ie: safari links against Carbon, libgcc/libogjc/etc, securityframework, etc) -- Why the concerns about the framework when what really matters is the user interface and performance? For all I care they could write the damn thing with QT and Java if it'd worked better than what we have now.

iTunes just doesn't fit in with other Mac OS X applications. It performs poorly, during on-the-fly encoding to 128 kbps AAC to my iPod and iPad it doesn't utilize that fact I have a Quad-Core processor with HT, the entire application slows to a crawl during initial syncing with devices, Preferences have to be applied with a "OK" or "Cancel" button not standard for Mac OS X, scrolling is much much slower than in other applications, it doesn't utilize Core Animation, etc.

While I'm not saying it's all the fault of Carbon alone there does seem to be a trend going on where Carbon applications feel very different from their Cocoa counterparts. QuickTime used to be Carbon as well, we saw a huge improvement in interface performance and overall look-'n'-feel when Apple rewrote it in Cocoa during Mac OS X Tiger development.

For all I care they could write the damn thing with QT and Java if it'd worked better than what we have now.

Doubtful you'll end up with an application that has a native look-'n'-feel with proper OS service integration. Again, not saying it's impossible, it's just very unlikely looking at every single application for Mac OS X that has been written that way.

Grand Master

the evn show

Posted
Posted

iTunes just doesn't fit in with other Mac OS X applications. It performs poorly, during on-the-fly encoding to 128 kbps AAC to my iPod and iPad it doesn't utilize that fact I have a Quad-Core processor with HT, the entire application slows to a crawl during initial syncing with devices, Preferences have to be applied with a "OK" or "Cancel" button not standard for Mac OS X, scrolling is much much slower than in other applications, it doesn't utilize Core Animation, etc.

Use of multiple processors has nothing to do with Cocoa, in fact I'd argue "best" (easiest) way to get access to a lot of cores in a cross platform application isn't to use cocoa. Core animation has nothing to do with scrolling of the nsscroll views, and the "okay/cancel" is also not a cocoa thing, it's a 'bad ui' thing.

All this hammering on "use cocoa" is misguided, it should be "fix the UI issues", "simplify the process <x,y,z>", "improve the handling of libraries of size xxx gb". Simply moving to cocoa won't fix any of those problems: there's nothing to stop Apple from building just as big a turd just because "[[their[code: looks]like]this];" instead of "looking(like(this)));"

I'd say there will be a move to possibly AV Foundation or at least QtKit will be sit ontop of AV Foundation which will be a bare bones basic framework.

iTunes is already using those libraries.

Cocoa allows 64bitness which includes better ASLR support, access to more registers, gaining benefits of GDC, compiler better optimisations etc.

iTunes isn't really the sort of Application which benefits from 64-bit guts. The only thing that iTunes does where it would be noticable is transcoding of audio. If you wanted to look at it as an "Apple is the devil" type of person you might say that transcoding isn't really part of Apple's business: their goals are for you to buy your music from them encoded and for you to buy larger ipods so you don't need to transcode. I'm not arguing that making audio encoding slow is part of some master plan to sell more ipods but it's understandable that this part of the applicaiton just isn't going to make it high on their list of priorities. Simply running more transcodes at once isn't something that is drastically easier in Cocoa than Carbon: it's a fairly easy problem to parallelize.

What sort of compiler optimizations do you think you'd get out using Cocoa that would be unavailable to Carbon? it's not like "gcc -o3" stops working just because you've chosen to link against some different set of libraries. It's already got access to GCD (I'm guessing that's what you mean by GDC) by nature of using CoreFoundation but it doesn't really matter. The majority of what iTunes does isn't CPU bound and it certain isn't going to perform drastically better just because you change the architecture it's targeting. The problems with iTunes aren't in the technology, they're in the design of the application.

I'm not doubting that iTunes will eventually use more Cocoa than it does now, one day, but I am doubtful that any issues people have it it are going to be addressed by a gradual change in technology. If iTunes does get better it'll have to do with revisiting their design decisions and not just because they checked a different box in xcode.

Grand Master

.Neo

Posted
Posted

Use of multiple processors has nothing to do with Cocoa, in fact I'd argue "best" (easiest) way to get access to a lot of cores in a cross platform application isn't to use cocoa. Core animation has nothing to do with scrolling of the nsscroll views, and the "okay/cancel" is also not a cocoa thing, it's a 'bad ui' thing.

All this hammering on "use cocoa" is misguided, it should be "fix the UI issues", "simplify the process <x,y,z>", "improve the handling of libraries of size xxx gb". Simply moving to cocoa won't fix any of those problems: there's nothing to stop Apple from building just as big a turd just because "[[their[code: looks]like]this];" instead of "looking(like(this)));"

Hence the reason why I said:

While I'm not saying it's all the fault of Carbon alone there does seem to be a trend going on where Carbon applications feel very different from their Cocoa counterparts.

It's just something you see: Practically all Carbon applications integrate poorly with the OS, suffer from odd non-standard interface quirks and have worse performance than their Cocoa counterparts. As such I think it's fairly logical that people who don't have advanced coding knowledge draw the conclusion that all the issues are directly Carbon related.

This topic is now closed to further replies.
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.