Mac OS X 10.5 (Leopard), iLife '07, and iWork '07 in March?

I haven't even looked up thesoftware that it's the icon for... I just like the look of it.

It's the icon for an open source program called Celestia.

image.php


Celestia Site
 
i'm talking about it not being virtual...the whole system running as 32bit systems use ram now...64bit would mean that all apps are accessing ram (then virtual memory when ram is full or "sleeping") and so basically what you're saying is that leopard will NOT be 64bit? it will only allow apps to be ran virtually as 64bit?

Sorry you misunderstand how operating systems work (don't take this the wrong way but your post is nonsensical)... you should read up on how virtual memory is used in modern operating systems.

Anyway... Leopard is a true 64 bit operating system... which means it supports running application with 64 bit address spaces (again virtual address space).
 
What is resolution independance?:confused:

See a prior post of mine https://forums.macrumors.com/showthread.php?p=3170636#post3170636 as well as the following...

Resolution Independence
The old assumption that displays are 72dpi has been rendered obsolete by advances in display technology. Macs now ship with displays that sport native resolutions of 100dpi or better. Furthermore, the number of pixels per inch will continue to increase dramatically over the next few years. This will make displays crisper and smoother, but it also means that interfaces that are pixel-based will shrink to the point of being unusable. The solution is to remove the 72dpi assumption that has been the norm. In Leopard, the system, including the Carbon and Cocoa frameworks, will be able to draw user interface elements using a scale factor. This will let the user interface maintain the same physical size while gaining resolution and crispness from high dpi displays.

The introduction of resolution independence may mean that there is work that you’ll need to do in order to make your application look as good as possible. For modern Cocoa and Carbon applications, most of the work will center around raster-based resources. For older applications that use QuickDraw, more work will be required to replace QuickDraw-based calls with Quartz ones.

Also see... Resolution Independent UI Release Notes for Mac OS X v10.4
 
"True 64-bit" as you describe it is worthless to the end user, and the developer. Unlike Windows, OS X using universal binaries, and libraries that are now compiled for both 32 and 64 bit... you can compile a binary to run the best it can on any of the 4 supported architectures. Add on top of that the fact that having 32-bit processes and 64-bit processes running at the same time don't interfere with each other... and there is no point on phasing out 32-bit support in the OS anytime in the next 6-7 years.

i never said it was worth while or worthless...i was explaining what 64bit was about to an end user..i also never said that 32 and 64 would interfere with each other...and i also did say that we wouldn't see true 64bit for a while now...anything else you'd like to add?
 
Sorry you misunderstand how operating systems work (don't take this the wrong way but your post is nonsensical)... you should read up on how virtual memory is used in modern operating systems.

Anyway... Leopard is a true 64 bit operating system... which means it supports running application with 64 bit address spaces (again virtual address space).

so are you telling me that when you refer to virtual memory you're not referring to swap files?

also i think you're misunderstanding me...i only said leopard was a step closer to everything being 64bit because it will allow the user to run 64bit applications...otherwise being true 64bit has nothing to do with leopard.. i was talking about when 32bit is no longer available, when we have systems that only use 64bit apps, where the whole os is only 64bit (not allowing 64/32 to be ran side by side)
 
I don't know where ThinkSecret is getting its information from but I don't believe this for a moment. As I and other have said before, due to the fact that we haven't seen a feature-complete version of the OS outside of Apple's labs yet (unless Steve was either not telling the truth or over-blowing what "secret features" actually entailed) this either implies that Leopard isn't anywhere near close to being ready or that Apple is going to be positively suicidal by releasing an OS that hasn't been widely tested yet.

My bet remains a release in June and I'd much prefer that at this moment than a rushed release in March.
 
Just watching and waiting

After wading through the previous posts, I have to say I agree with those who just want a stable release. Whether it's March or June is less important. I wouldn't be surprised to see an announcement in March with a release in April or May.

My only problem is that I'm still on an iBook G3, and I can't afford a Macbook.
 
I hope they package iLife with the OS, they go together, that is what is shown to bring the switchers so they should come together.

Bring it on!!!!!!!!!!!!!!!
:cool:

switchers have to BUY a new mac, so they will have leopard & iLife 07 in the box
 
If the "secret" of leopard doesn't require developers testing...could it possibly be just an UI change? Like the ever rumoured "Illuminous" GUI.

Unlikely. Changing the UI used by current applications very much would require testing -- interface components aren't going to be exactly the same sizes, baselines might shift a bit, and so forth -- not to mention the fact that developers would want the chance to adjust their color choices, fonts, and so forth to better fit the new theme. Making major changes to the default appearance of Aqua without warning wouldn't be a good move on Apple's part.

They could of course introduce another theme alongside the existing ones, using it for their own apps without disturbing current applications. That's really the only scenario that would make sense as a surprise new feature, and while it's certainly possible I think people are getting ahead of themselves. Keep in mind that brushed metal was such a new theme -- and consider that you might be getting excited over what basically amounts to a new brushed metal.

One important thing to note: leaked screenshots of Leopard have demonstrated how many of Aqua's interface elements, such as the close / minimize / zoom buttons on windows, which did not properly support resolution independence in Tiger now do in Leopard. The fact that Apple is taking the time to make Aqua elements support a Leopard-only feature strongly suggests that Aqua will continue to look much the same in Leopard.
 
One important thing to note: leaked screenshots of Leopard have demonstrated how many of Aqua's interface elements, such as the close / minimize / zoom buttons on windows, which did not properly support resolution independence in Tiger now do in Leopard. The fact that Apple is taking the time to make Aqua elements support a Leopard-only feature strongly suggests that Aqua will continue to look much the same in Leopard.
On the contrary, the Leopard builds so far have barely touched any of the artwork. The window glyphs as far as I'm aware are the only ones that have been replaced, and likely just for testing purposes.

Further, there is almost no outside testing required, especially given that developers are working on implementing resolution independence (Apple requests that developers get it done by 2008). Do XP apps need to be updated for Vista? Did 2000 ones for XP? Does every KDE theme need to be tested against thousands of applications? The answer to all of these things is "no." Unless you're expecting some radical new approach to the way we interact with computers, there's no reason that there needs to be widespread public testing six months in advance. All the big apps will be exempt or tested internally and notified. The small ones don't have access to developer software anyway, so it doesn't matter. The relatively narrow middle ground band is the only affected group, and the likelihood of problems itself is quite small. If anything, all the apps not ready for resolution independence will stay Aqua and everything upgraded will go with the new style--RXScrollbar instead of NSScrollbar and so forth.
 
After wading through the previous posts, I have to say I agree with those who just want a stable release. Whether it's March or June is less important. I wouldn't be surprised to see an announcement in March with a release in April or May.

My only problem is that I'm still on an iBook G3, and I can't afford a Macbook.

Being on an iBook G3, is not a real problem is it? It just shows the longlivity of Apple's designs, eventhough it's 'old' in computer terms, it is not yet obsolete :)
 
On the contrary, the Leopard builds so far have barely touched any of the artwork. The window glyphs as far as I'm aware are the only ones that have been replaced, and likely just for testing purposes.

Many of the images have been updated -- unless I misremember, radio buttons, check boxes, and other components did not scale cleanly in Tiger. They do in Leopard.

Further, there is almost no outside testing required, especially given that developers are working on implementing resolution independence (Apple requests that developers get it done by 2008). Do XP apps need to be updated for Vista? Did 2000 ones for XP? Does every KDE theme need to be tested against thousands of applications? The answer to all of these things is "no."

Sure, they could drop a major UI overhaul on everyone without giving developers the chance to test it. I didn't say that it was impossible, merely that it would be a bad move on Apple's part, and I stand by that.

And yes, applications did need to be tested against Vista. Hence the huge, lengthy beta process. Sure, most of the problems were unrelated to the visual changes, but I'm sure more than a few issues were discovered. I know at least one product at my company required updates for specifically for Aero.

I'm not in any way suggesting that most applications wouldn't work just fine with a changed theme. But there are going to be (as there always are) a handful of exceptions, which is why these developer seeds are important. I maintain that if Apple were to spring a significant UI change on everyone without giving developers the chance to test against it first, it would be crappy policy. Not impossible, but crappy.
 
In what way? Other than visually speaking (because the UI glyphs and widgets are not themselves ready), my impression was that resolution independence seems finished. I'm curious; what's broken?

The underlying framework is done, but I still see lots of issues with Apple's own software. Mostly minor things -- the middle part of a component being shifted up a pixel relative to the left and right ends, a blank pixel between two images which are supposed to be adjacent, and (can't remember if this is in the current seed or the one prior to it) at least one major application which is still running in magnified mode. For the non-developers out there, imagine implementing resolution independence by taking a picture of your screen, scaling it up using nearest-neighbor interpolation, and calling it resolution independent. That's magnified mode, and at least one major Apple application was still running that way when I last checked.

There are a few major issues as well; I've had Safari get horribly confused about the current scale factor and draw images at different scale than text, or perform layout using a scale of 1.0 but drawing using my specified scale, causing all of the content to be clipped horribly. Doesn't happen all the time, but it's happened more than once and it renders the browser basically unusable.

None of these are worrisome for, say, a May or June release. But March strikes me as unrealistic.
 
Many of the images have been updated -- unless I misremember, radio buttons, check boxes, and other components did not scale cleanly in Tiger. They do in Leopard.
I recall those working, along with text. But it has been a while, and if you are right, it's still no big deal to replace checkboxes and radios. Last I checked, all the animated parts still didn't work right (zooming rather than scaling), and a healthy number of icons, buttons, and other odds and ends didn't work.
Sure, they could drop a major UI overhaul on everyone without giving developers the chance to test it.
Right, but they're not going to spring it on us the night of the launch party--it'll show up in the final few builds when developers are doing the cleanup phase (which includes minor UI issues). They still have plenty of time to test it, even if it's coming in late March (which I, like you, highly doubt). More to the point though, they don't need advance testing if Apple intends to roll the new UI out with renamed resources (rather than NSresources), meaning that apps won't be affected until developers choose to flip the switch.

Sure, most of the problems were unrelated to the visual changes, but I'm sure more than a few issues were discovered.
Effectively zero were a result of the visual changes. I have yet to see a single report of a single application which suddenly bugged out on Vista as a result of the new visual style (not due to the API changes).
I know at least one product at my company required updates for specifically for Aero.
In what way? For Aero glass, perhaps you had some outdated calls which reverted the app to Aero basic, but that's not really a bug. The only thing that bothers me about the Aero basic is that it knocks back the entire system instead of just the affected application. Other than that, it's essentially the same setup as I would implement, were I Apple (incompatible applications appear as Aqua applications without impacting the rest of the system's appearance).
But there are going to be (as there always are) a handful of exceptions, which is why these developer seeds are important. I maintain that if Apple were to spring a significant UI change on everyone without giving developers the chance to test against it first, it would be crappy policy. Not impossible, but crappy.
I agree in principle, but the reality is that the developers who have access to developer seeds either have the resources to fix any glitches in a matter of days (and therefore don't need the UI until the final few seeds) or they aren't going to change their schedule because of it anyway (and therefore don't care when the beta is seeded). There's no sense in waiting for developers whose applications are used by 1-2% of the user base to correct a minor bug. This is particularly true if the new UI has an amnesty phase-in like most other Apple transitions.

I've done some work on this in the past. I know how fast fixes come when they're motivated and how slow they come when the priorities are elsewhere. I also know that the problem rate is remarkably small (I've watched near flawless rollouts) and only happens where some programmer did something they shouldn't have as a quick hack. The reality is that no matter how long they delay, some small app somewhere is going to have a problem. As long as it doesn't affect a large number of users, it's not going to be a real issue.
 
I call BS. End of March is highly unrealistic based on the fact no rumors of an RC have even been leaked much less a GM. Apple would need at least 4-6 weeks to press, package, and ship enough copies for launch and pre-order fulfilment.

It's almost the middle of Feb. Apple gives reporters, etc, a week heads up on Apple events. No invites yet, so the earliest an Apple event could happen is the 19th IF Apple sent out invites on Monday. That would give Apple enough time to press and ship Leopard IF if was complete. But its not complete. There is no GM yet. It's close, but no cigar. 10.4.9 isn't even out yet. So the reality of Leopard in March I think is nill. Maybe we'll get a release date in March, but no product.
 
so are you telling me that when you refer to virtual memory you're not referring to swap files?
No I am not refering to swap files.

Applications on modern operating system live in a virutal address space... one that the OS is free to map as needed to physical memory. This is how multiple application share the pool of physical memory attached to the system (also how the file cache is managed on Mac OS X, etc.). Having 64 bit addressing does not change the fundamental need for virtual addressing nor does virtual addressing only imply swap files.

Yes virtual memory systems can use swap files as needed to deal with over demand situations but that is just one aspect of what virtual memory systems do.

also i think you're misunderstanding me...i only said leopard was a step closer to everything being 64bit because it will allow the user to run 64bit applications...otherwise being true 64bit has nothing to do with leopard.. i was talking about when 32bit is no longer available, when we have systems that only use 64bit apps, where the whole os is only 64bit (not allowing 64/32 to be ran side by side)
Again what the heck is "true 64 bit" or "full 64 bit" ... it is an arbitrary and generally unimportant line that you have drawn.

Leopard is a 64 bit operating system that also allows 32 bit application to run... going 64 bit doesn't make sense for many classes of applications and so Leopard (and likely Mac OS X for the next few major releases) do not force you to covert your application to 64 bit.

Will Mac OS X some day drop support for running 32 bit applications? Likely but we are talking far in the reasonable distant future and well after advances in hardware eclipse some of the negatives of 64 bit applications and the pool of 32 bit only hardware has been replaced with 64 bit capable hardware. The main reason they would drop support is to save on code size (don't have to ship 32 bit libraries/frameworks).
 
I find March extremely unlikely. Steve Jobs isn't the type for a quiet launch of an operating system. He would have taken a minute or two out of they keynote to give a date.
 
I agree. Email templates - Wow!

Really disheartened with Apple recently. Hopefully there will be something simply awesome in Leopard that they have held back until the last moment.

I really really want to see an interface refresh, I'm not saying overhaul, that brings OS X up to Vista's eye-candy - I agree with the Wired Mac guy, OS X looks slightly dated in comparison.

I don't care if it's right, but half the attraction of an Apple Mac for me was its attractive design, both on screen and off. I don't want a £399 Dell running Vista making my Mac look less attractive - So c'mon Apple, satisfy my vanity.

Bring OS X "up to" Vista's candy? Is this a joke? Please, if you go as far enough as to think that Vista is more advanced than OS X in any sense (including design), please buy a copy from MS...there is no use in participating in a Mac forum, man.

OS X is miles ahead of Vista in design, and does not equate that stupid mix of copycat transparency with clutter...Vista plain sucks, period.
 
The Full Package

Maybe Apple is thinking of pushing even further the "full package" selling point that Steve made at WWDC. Vista has some DVD video burning capabilities built in, if I understand correctly. This may push Apple to bundle iLife with Leopard. Maybe they'd do the same for iWork (AppleWorks used to be included on some machines).

It'd be a lost revenue stream BUT with all the comparisons that will be made between Leopard and Vista, it'd make Leopard that much more impressive of a package....
 
Maybe Apple is thinking of pushing even further the "full package" selling point that Steve made at WWDC. Vista has some DVD video burning capabilities built in, if I understand correctly. This may push Apple to bundle iLife with Leopard. Maybe they'd do the same for iWork (AppleWorks used to be included on some machines).

It'd be a lost revenue stream BUT with all the comparisons that will be made between Leopard and Vista, it'd make Leopard that much more impressive of a package....

As much as id love that, i dont think thats how Apple thinks. They don't care that some features that mac and MS both share, MS is giving away free in Vista. ilife wills till come on the machines but chances are (and i hope im wrong) they wont bundle them together. However, they may do it for this major point seeing as this is when a lot of PC users are switching over to Mac, making it look a lot better, however, then they are just buying a new computer and not leopard seperatly, so no i dont see it happening.
 
No I am not refering to swap files.

Applications on modern operating system live in a virutal address space... one that the OS is free to map as needed to physical memory. This is how multiple application share the pool of physical memory attached to the system (also how the file cache is managed on Mac OS X, etc.). Having 64 bit addressing does not change the fundamental need for virtual addressing nor does virtual addressing only imply swap files.

Yes virtual memory systems can use swap files as needed to deal with over demand situations but that is just one aspect of what virtual memory systems do.

Again what the heck is "true 64 bit" or "full 64 bit" ... it is an arbitrary and generally unimportant line that you have drawn.

Leopard is a 64 bit operating system that also allows 32 bit application to run... going 64 bit doesn't make sense for many classes of applications and so Leopard (and likely Mac OS X for the next few major releases) do not force you to covert your application to 64 bit.

Will Mac OS X some day drop support for running 32 bit applications? Likely but we are talking far in the reasonable distant future and well after advances in hardware eclipse some of the negatives of 64 bit applications and the pool of 32 bit only hardware has been replaced with 64 bit capable hardware. The main reason they would drop support is to save on code size (don't have to ship 32 bit libraries/frameworks).

thanks for clearing up the virtual memory!!! and my "true 64bit" is exactly what you state, that 32 will be dropped EVENTUALLY...as i stated before we're a long ways off...but was i wrong in stating that when 32bit is no longer, that we'd need more than 4gigs of ram for 64bit programs to access...otherwise my mentioning of leopard (i will say it again) has NOTHING to do with me talking about 64bit, except that we're one step closer to being true 64bit...i never said anything about 32bit or 64bit interfering (you didn't mention this, somebody else did)..i also never said that it made sense for apps to be 64bit, if you'll re-read my posts, i clearly stated that we don't have need for even 1 or 2 apps to be 64bit yet
thanks again for clearing up the virtual memory
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Back
Top