Delayed help would probably work out. Leave your mouse over the grayed out option for more than 2-3 seconds and a little "click here to find out why this has been disabled" could be useful.
Or, even better, you could just put the reason in the tooltip text and save the clicking.
I know at least with Cocoa you're already validating menu items and tooltip support is almost universal - so it'd be easy for apple to enable tooltips for menu items without even changing the API. Maybe I'll head over to radar...
Does it strike anybody else as odd that you manage your photos on this thing using iTunes instead of iPhoto where you are presumably managing your photos? I realize that iTunes already has all the iPod management code built in and that it would be awkward to have iPhoto and iTunes working to manage the iPod at the same time - but it still feels contrived.
Maybe we're supposed to just deal with it until Apple gets Tiger out the door and Sync services are built into the OS proper? It just doesn't feel very Mac-Like this way...
Almost all of the missing features I'm seeing people bitch about here (camera, card reader, etc) will be available as third party options that connect to the dock port. I'll guarantee that for you...
I completely agree - so I wrote my own: Feed. It's still got some rough edges, but works well enough for everyday use, is Open Source and supports RSS and Atom.
'Fraid not. Snowball, part 1 of the Silicon Dreams trilogy from Level 9
Dang! I didn't remember it as a line from Plantefall exactly (it WAS over 15 years ago!) - just was guessing based on style. Thanks for the info - I'll check it out. I could use a touch of nostalgia (maybe even connect up to the old Mud I used to play...)
Wow - you're right. I could have sworn I heard Apple trumpeting about that change, but I seem to have mixed one of those silly rumors with real life. Damned pre-coffee posts.
That only strengthens my original point, though - with the only difference being that Apple hasn't moved any of their applications from one framework to the other. Apple themselves treat Carbon and Cocoa as equals and the proof is in the Applications they develop.
all Mac OS X native programs are written in Cocoa, Carbon, or Java
<pedantic>Actually, Cocoa, Carbon and Swing are the frameworks you can use. Java, Objective-C, AppleScript, Python and Perl (and more every day) are languages you may choose from in order to target those frameworks.</pedantic>
Cocoa and Carbon are both considered 'native', though. For a new project, the only real choice is wether you want to go procedural and target Carbon or OO and target Cocoa. Legacy code bases will naturally choose Carbon to leverage existing code, but there are virtually no differences in capabilities (now - there were) between the two frameworks now.
In fact, most of the Cocoa objects use the same low level data structures and functions under the hood as the Carbon framework - so much so that Apple offers 'Toll Free Bridging' between the types. An NSString object can be swapped with a CFString reference without having to convert it at all. The idea here is to encourage 'hybrid' Cocoa/Carbon applications - but the the fact that this works proves that there isn't much difference under the hood between the frameworks.
The advantage of using the Cocoa framework is simply being able to use Objective C (very funky at first, but very cool language) and an extremely elegant framework that does most everything you might need with minimal work. If you're starting a new project, you should be using Cocoa. It's fast, powerful and is Apple's Wave Of The Future. I don't expect Carbon to go away any time soon (you try telling Adobe that they have to rewrite Photoshop from scratch), but I do expect lack of effort at some point. This doesn't mean that Carbon is somehow non-native.
iTunes is a legacy application (released initially for OS 9), therefore it was started on the Carbon framework. However, a LOT of the refinements Apple developed using iTunes (alternating row colors on lists, split views, controls in table cells, etc) has made it down into the frameworks and are now available to both Cocoa and Carbon.
PS - Interesting tidbit: The Finder was initially a (badly) modified Carbon application when OS X was first released. It was re-written in Cocoa for 10.2, and I believe it is the ONLY Apple application that has made that transition. It's either a testament to the simplicity of the Finder (right) or the power of Cocoa (likely) that they were able to change so easily. Not that I don't have my gripes...
Every one of those except the last one indicates that cause of death was from inhaling Helium directly from a commercial canister, not from the Helium per se. The last one was an injury caused by passing out from oxygen deprivation - again the Helium itself is NOT to blame.
Moral of the story? Don't stick your lips on a machine designed to fill a balloon to capacity within a couple of seconds!
I never see anything about what type of screw goes where.
Can you realistically tell the difference between them by sight? Some of the screws in their laptops differ by fractions of millimeters.
The trick I use (and is also mentioned in Apple's training manuals): grab an empty ice cube tray. For each step in disassembly, use a different ice cube slot. While this may not help much for a step that has a lot of screws (eg - taking the top plate off of an iBook), it's certainly better than nothing!
Preach it brother! I've been toolin' around in my $400 '81 Toyota Starlet for over a year now, and I swear the thing has got another 100K miles in it.
Even with $20 a month on gas (at ~$2 a gallon!) and insurance, my work has ended up paying for that car three times over with my expense reimbursements for mileage. I'll drive it into the ground, then go find another one - though I will admit that it sounds like you are driving around in an empty beer can when it rains (and it rains here in Eugene).
but it's unclear whether it needs to be an OS X box, or if it'll work with other operating systems at its core.
Well, according to Apple's Xsan site: You may also use Xsan in a cross-platform environment alongside Windows-, UNIX- and Linux-based systems, using the ADIC StorNext File System, which is 100% interoperable with Xsan.
My favorite part on that page is where they mention that you don't need a dedicated metadata server: If this machine fails for any reason, Xsan picks another computer on the SAN to take over this role. Cascading metadata controller failover ensures that you can access your data as long as any one system on your SAN is active.
I've been an iTunes user for years, and this is exactly what I've been wanting this whole time. Smart playlists are getting there, but being able to add in topical / usage data to the criteria would be absolutely killer.
Shuffle all songs in the most played genres giving preference to:
Songs that have been added to the library in the last week
Songs that haven't been played for over six months
Songs that have a high rating, but haven't been played in the last month
Songs that have high play count, but low/no rating
It makes me wonder if he's ever bothered to select a bunch of pictures and just drag them somewhere.
Or just navigated to '~/Pictures/iPhoto Library' and grabbed the pictures manually. Granted, that's not too easy for the casual user - but that's what dragging them out of iPhoto directly is for, right? Proprietary my shiny metal ass...
How many years has IPv6 been in the works? How many million man-hours of committee time has it already been through? How close are we all to deploying IPv6?
IPv6 doesn't offer any compelling advantages to the average internet user, whereas anything that cuts down on the amount of spam in their inboxes is worth any inconvenience. The pressure of expansion in the current IPv4 address space doesn't get them pumped up. Penis enlargement advertisements do.
Well, yeah, but people have been saying for years that most CDs have only one or sometimes two songs that most purchasers want. So in most caseds, a single-tune download has literally replaced a single CD sale.
Something that nobody seems to be mentioning while busy pointing out the discrepancy in the article summary - and I think it's a big point: People are buying songs online that they want and not the ones that happen to be released on a single.
How many of you have even thought about buying a single since the demise of the 45? How many of you are considering it now?
this is not because these projects are using 10.2 specific features; they're binary compatibility requirements
Apple initially released a binary API in 10.0 that would allow as much compatibility as possible with existing tools (mostly the stuff they grabbed from NeXT), but they had every intention of moving to the new one as soon as they could. With the release of 10.2, they made that change.
Sure, this broke the old apps, but they needed to do it, and wanted to do it as soon as possible so that other application developers wouldn't be hit so hard by it. Would you rather have had them wait until this revision to make the change? The amount of third party applications out there right now is significantly larger than it was when they released 10.2.
You are assuming that Apple will change the API again - which is not the case at all. They had to make a change, and they did it as soon as they could. Given the (relatively) seamless transition from OS 9 to OS X as a whole, I can forgive them this single issue.
Finally, this is hardly an Apple only issue. Anybody remember having to bump glibc versions? By hand? With some legacy apps that didn't like the new version? On a live system? I sure do...
Slashdot Mirror
I know at least with Cocoa you're already validating menu items and tooltip support is almost universal - so it'd be easy for apple to enable tooltips for menu items without even changing the API. Maybe I'll head over to radar...
And on the back of that sign it said (scribbled out): "Weed, $40 for an ayth"
Dude, that was the plot to Superman III
Looks like there's a lot more work to do. Only a few minutes in and ... The Usual.
Does it strike anybody else as odd that you manage your photos on this thing using iTunes instead of iPhoto where you are presumably managing your photos? I realize that iTunes already has all the iPod management code built in and that it would be awkward to have iPhoto and iTunes working to manage the iPod at the same time - but it still feels contrived.
Maybe we're supposed to just deal with it until Apple gets Tiger out the door and Sync services are built into the OS proper? It just doesn't feel very Mac-Like this way...
I completely agree - so I wrote my own: Feed. It's still got some rough edges, but works well enough for everyday use, is Open Source and supports RSS and Atom.
The second Amendment to the constitution is: You will not talk about the constitution!
Dang! I didn't remember it as a line from Plantefall exactly (it WAS over 15 years ago!) - just was guessing based on style. Thanks for the info - I'll check it out. I could use a touch of nostalgia (maybe even connect up to the old Mud I used to play...)
Planetfall?!
Wow - you're right. I could have sworn I heard Apple trumpeting about that change, but I seem to have mixed one of those silly rumors with real life. Damned pre-coffee posts.
That only strengthens my original point, though - with the only difference being that Apple hasn't moved any of their applications from one framework to the other. Apple themselves treat Carbon and Cocoa as equals and the proof is in the Applications they develop.
<pedantic>Actually, Cocoa, Carbon and Swing are the frameworks you can use. Java, Objective-C, AppleScript, Python and Perl (and more every day) are languages you may choose from in order to target those frameworks.</pedantic>
Cocoa and Carbon are both considered 'native', though. For a new project, the only real choice is wether you want to go procedural and target Carbon or OO and target Cocoa. Legacy code bases will naturally choose Carbon to leverage existing code, but there are virtually no differences in capabilities (now - there were) between the two frameworks now.
In fact, most of the Cocoa objects use the same low level data structures and functions under the hood as the Carbon framework - so much so that Apple offers 'Toll Free Bridging' between the types. An NSString object can be swapped with a CFString reference without having to convert it at all. The idea here is to encourage 'hybrid' Cocoa/Carbon applications - but the the fact that this works proves that there isn't much difference under the hood between the frameworks.
The advantage of using the Cocoa framework is simply being able to use Objective C (very funky at first, but very cool language) and an extremely elegant framework that does most everything you might need with minimal work. If you're starting a new project, you should be using Cocoa. It's fast, powerful and is Apple's Wave Of The Future. I don't expect Carbon to go away any time soon (you try telling Adobe that they have to rewrite Photoshop from scratch), but I do expect lack of effort at some point. This doesn't mean that Carbon is somehow non-native.
iTunes is a legacy application (released initially for OS 9), therefore it was started on the Carbon framework. However, a LOT of the refinements Apple developed using iTunes (alternating row colors on lists, split views, controls in table cells, etc) has made it down into the frameworks and are now available to both Cocoa and Carbon.
PS - Interesting tidbit: The Finder was initially a (badly) modified Carbon application when OS X was first released. It was re-written in Cocoa for 10.2, and I believe it is the ONLY Apple application that has made that transition. It's either a testament to the simplicity of the Finder (right) or the power of Cocoa (likely) that they were able to change so easily. Not that I don't have my gripes...
Or both. The one in the fridge is backup - the one on the abdomen is so you don't have to get off the floor as often.
Every one of those except the last one indicates that cause of death was from inhaling Helium directly from a commercial canister, not from the Helium per se. The last one was an injury caused by passing out from oxygen deprivation - again the Helium itself is NOT to blame.
Moral of the story? Don't stick your lips on a machine designed to fill a balloon to capacity within a couple of seconds!
Um, I think the filesystem is either fixed by now or completely fucked. Stop running the check...
Can you realistically tell the difference between them by sight? Some of the screws in their laptops differ by fractions of millimeters.
The trick I use (and is also mentioned in Apple's training manuals): grab an empty ice cube tray. For each step in disassembly, use a different ice cube slot. While this may not help much for a step that has a lot of screws (eg - taking the top plate off of an iBook), it's certainly better than nothing!
Preach it brother! I've been toolin' around in my $400 '81 Toyota Starlet for over a year now, and I swear the thing has got another 100K miles in it.
Even with $20 a month on gas (at ~$2 a gallon!) and insurance, my work has ended up paying for that car three times over with my expense reimbursements for mileage. I'll drive it into the ground, then go find another one - though I will admit that it sounds like you are driving around in an empty beer can when it rains (and it rains here in Eugene).
Well, according to Apple's Xsan site: You may also use Xsan in a cross-platform environment alongside Windows-, UNIX- and Linux-based systems, using the ADIC StorNext File System, which is 100% interoperable with Xsan.
My favorite part on that page is where they mention that you don't need a dedicated metadata server: If this machine fails for any reason, Xsan picks another computer on the SAN to take over this role. Cascading metadata controller failover ensures that you can access your data as long as any one system on your SAN is active.
Cool stuff indeed!
And this is somehow different than 2000 Techno songs on shuffle?
Shuffle all songs in the most played genres giving preference to:
- Songs that have been added to the library in the last week
- Songs that haven't been played for over six months
- Songs that have a high rating, but haven't been played in the last month
- Songs that have high play count, but low/no rating
I'd be in heaven!Or just navigated to '~/Pictures/iPhoto Library' and grabbed the pictures manually. Granted, that's not too easy for the casual user - but that's what dragging them out of iPhoto directly is for, right? Proprietary my shiny metal ass...
IPv6 doesn't offer any compelling advantages to the average internet user, whereas anything that cuts down on the amount of spam in their inboxes is worth any inconvenience. The pressure of expansion in the current IPv4 address space doesn't get them pumped up. Penis enlargement advertisements do.
Er, you know what I mean...
How many of you have even thought about buying a single since the demise of the 45? How many of you are considering it now?
Don't forget that some of those apps in the Classic environment were written for an entirely diffent architecture!
Apple initially released a binary API in 10.0 that would allow as much compatibility as possible with existing tools (mostly the stuff they grabbed from NeXT), but they had every intention of moving to the new one as soon as they could. With the release of 10.2, they made that change.
Sure, this broke the old apps, but they needed to do it, and wanted to do it as soon as possible so that other application developers wouldn't be hit so hard by it. Would you rather have had them wait until this revision to make the change? The amount of third party applications out there right now is significantly larger than it was when they released 10.2.
You are assuming that Apple will change the API again - which is not the case at all. They had to make a change, and they did it as soon as they could. Given the (relatively) seamless transition from OS 9 to OS X as a whole, I can forgive them this single issue.
Finally, this is hardly an Apple only issue. Anybody remember having to bump glibc versions? By hand? With some legacy apps that didn't like the new version? On a live system? I sure do...