Photoshop is still Carbon? Gadzooks! How long has Cocoa been out now, five years? Come on, Adobe, stop clinging to ancient code. You have to make the change sooner or later. CS3 - Universal - Cocoa, just do it.
Oh no, you didn't just say that did you?
Quote:
Originally Posted by Chucker
You just had to, didn't you.
Maybe we need a sticky at the top of the Mac OS forum that says "Cocoa isn't all that!"
There are many things that you can do in Carbon that you just can't do in Cocoa, or couldn't until very recently. One big one is leverage all the QuickTime APIs, and I imagine that that's a big reason why Photoshop is still Carbon.
I doubt that'll ever happen. Cross platform apps don't use cocoa for the reason that those APIs are not on other platforms so it doesn't make sense to use them on the Mac especially in large programs. .
As someone has said - carbon also isn't available on Windows. The big developers use their own environments to aid in writing for Mac and Win simultaneously, but it hurts them when Apple makes a huge change as they're left out while everyone recompiles under Xcode.
Cocoa used to be on windows and Unix via OpenStep, and Carbon frameworks were apparently available for Windows, via Quicktime (unofficially). Nothing that really helps a developer write in Cocoa/Carbon for both though anymore.
I've tried it in Tiger--very cool but still rough of course--it's only there for developers to test with. If you want to try it, every Tiger DVD comes with the Quartz Debug app that can enable the feature.
(Get Pacifist from versiontracker.com if you want to install just Quartz Debug without the rest of the dev tools.)
If carbon and cocoa APIs were available on Windows, do you really think a major application developer like Adobe would develop solely with Carbon/Cocoa or continue using the Windows API's their using now?
If carbon and cocoa APIs were available on Windows, do you really think a major application developer like Adobe would develop solely with Carbon/Cocoa or continue using the Windows API's their using now?
They don't use the Windows API, at least not at the level I think you're meaning. They have their own framework they use for user interfaces to create cross platform applications.
At least ten years ago, I wondered why interfaces were laid out with absolute numbers of pixels like in Visual Basic 3, ResEdit and Interface Builder. They should have been done with a proportion (like a fraction between 0.000 and 1.000) of the length and/or width of the window. The font size of the text would be controlled by the enclosing item (button, text box) and the size of the string in the language used and mirrored vertically for right-to-left languages like Hebrew and Arabic.
I didn't do anything with those thoughts, but now it's called "resolution independence" and it's suddenly all sexy and that! Damn, I could have been the father of all that!
*Ten points if you can name that quote.
No, that's the wrong way to do it too.
You should only really hint where interface elements should be. eg. this button goes to the left of this entry field. It's not new, we were doing this 20 years ago at a company I worked at that produced cross platform code that ran on DOS, OS/2, Windows and Motif using the same binary.
According to the posting at AeroXperience, Carbon applications -- those build upon the Classic Mac OS programming interfaces -- can be embedded with Cocoa views under Leopard. Speculation is that this interoperability could provide applications like Photoshop and Microsoft Office access to advanced functions previously only available to Cocoa applications"
Funnily enough, guess who is probably sending the largest (or second largest) contingent of developers to WWDC? I wonder how the developers from the MicroShaft Mac Business Unit understand the NDA. In theory, they should be absolutely forbidden from discussing secrets with anyone in the other units of the company! In reality, I'm sure Ballmer et al. come down and say, "Hey, guys, we just spent hundreds of thousands of dollars sending you to WWDC. What did you find out?"
It is my hope the despicable leaker and corporate sponsor can be identified by Apple and thoroughly trounced.
Fonts should be described in standardized print point sizes, not pixels. So that would make the display more like printers, when someone buys a higher dpi printer, they don't expect that the printed image is half the intended size. That and when someone choses a larger system font for easier readability, without resolution independence, it breaks a lot of controls as the text gets cut off.
Not true for web design ...
Font size should ALWAYS BE IN PIXELS for control of the look of a page, make a CSS for print using points - thats what it is for. Points are for printers only. This is easy typography 101 stuff. If you want to make is so people can use there own font size and do not care about how the page is rendered use EM's.
Every screen renders pixels the exact same size, points and EM's are rendered different from system to system and monitors.
A 15" screen with native 800 x 600 does not have pixels the exact same size as one with native 1600 x 1200.
From the link I posted:
"if control over the look of your Web page is your biggest concern, then you should use pixels. Pixels are the standard unit of measure for screens and monitors, and fonts will be more precisely the size you want on the screen."
"if control over the look of your Web page is your biggest concern, then you should use pixels. Pixels are the standard unit of measure for screens and monitors, and fonts will be more precisely the size you want on the screen."
My point was that pixels are not always the same size. If you use pixels in your webpage, yes, you know that the layout can't get borked and the relative positions of everything will always be the same, no matter what resolution it is viewed in. But, the higher the resolution of the screen, the smaller the content. This is what resolution independence is for: maintaining relative positions etc. but keeping everything at a readable size whilst allowing for high-detail imagery.
My point was that pixels are not always the same size. If you use pixels in your webpage, yes, you know that the layout can't get borked and the relative positions of everything will always be the same, no matter what resolution it is viewed in. But, the higher the resolution of the screen, the smaller the content. This is what resolution independence is for: maintaining relative positions etc. but keeping everything at a readable size whilst allowing for high-detail imagery.
Yes however using Points or EM will break your design no matter what. Fonts rendered in Pixels will always be rendered the same size in proportion to images and other elements. I do not see how using Points will work better than Pixels in resolution independence.
Ideally any resolution independence would look at the font size and enlarge it or shrink it the same way it does images.
I don't think any of these are the "top secret" features that Jobs alluded to at all.
He's not going to say, "there are some things we're keeping close to our vest so our friends up North don't start their copiers just yet" and then the same day hand everyone a DVD containing any of those features.
These are just things that weren't deemed headline important enough to hit the top 10 demos.
The real top secret things won't be on Leopard Preview until they are no longer top secret. I'm guessing things like a revamped Finder, an app that could more or less just appear later on without affecting developers use of the OS X APIs, which is why they need Leopard now.
Yes however using Points or EM will break your design no matter what. Fonts rendered in Pixels will always be rendered the same size in proportion to images and other elements. I do not see how using Points will work better than Pixels in resolution independence.
Ideally any resolution independence would look at the font size and enlarge it or shrink it the same way it does images.
12 points implies 12 pixels at 72 DPI. 12 pixels implies 12 pixels at any DPI.
So, a user with a 200 DPI screen of the future will need phenomenal eyesight to read a 12 pixel font—it will only be 1.5mm. They'll have no problem reading the 12 point font type which'll be 4.23mm.
I don't think you understand resolution independence very well....
In all likelihood, since the web ISN'T coded for resolution indendence, it'll scale pixels anyway, though.
Comments
- Mark
Photoshop is still Carbon? Gadzooks! How long has Cocoa been out now, five years? Come on, Adobe, stop clinging to ancient code. You have to make the change sooner or later. CS3 - Universal - Cocoa, just do it.
Oh no, you didn't just say that did you?
You just had to, didn't you.
There are many things that you can do in Carbon that you just can't do in Cocoa, or couldn't until very recently. One big one is leverage all the QuickTime APIs, and I imagine that that's a big reason why Photoshop is still Carbon.
Cross platform apps don't use cocoa for the reason that those APIs are not on other platforms
I doubt that'll ever happen. Cross platform apps don't use cocoa for the reason that those APIs are not on other platforms so it doesn't make sense to use them on the Mac especially in large programs. .
As someone has said - carbon also isn't available on Windows. The big developers use their own environments to aid in writing for Mac and Win simultaneously, but it hurts them when Apple makes a huge change as they're left out while everyone recompiles under Xcode.
Cocoa used to be on windows and Unix via OpenStep, and Carbon frameworks were apparently available for Windows, via Quicktime (unofficially). Nothing that really helps a developer write in Cocoa/Carbon for both though anymore.
http://developer.apple.com/releaseno...pendentUI.html
I've tried it in Tiger--very cool but still rough of course--it's only there for developers to test with. If you want to try it, every Tiger DVD comes with the Quartz Debug app that can enable the feature.
(Get Pacifist from versiontracker.com if you want to install just Quartz Debug without the rest of the dev tools.)
If carbon and cocoa APIs were available on Windows, do you really think a major application developer like Adobe would develop solely with Carbon/Cocoa or continue using the Windows API's their using now?
They don't use the Windows API, at least not at the level I think you're meaning. They have their own framework they use for user interfaces to create cross platform applications.
See http://opensource.adobe.com/
Instead of a bum, which is what I am! *
At least ten years ago, I wondered why interfaces were laid out with absolute numbers of pixels like in Visual Basic 3, ResEdit and Interface Builder. They should have been done with a proportion (like a fraction between 0.000 and 1.000) of the length and/or width of the window. The font size of the text would be controlled by the enclosing item (button, text box) and the size of the string in the language used and mirrored vertically for right-to-left languages like Hebrew and Arabic.
I didn't do anything with those thoughts, but now it's called "resolution independence" and it's suddenly all sexy and that! Damn, I could have been the father of all that!
*Ten points if you can name that quote.
No, that's the wrong way to do it too.
You should only really hint where interface elements should be. eg. this button goes to the left of this entry field. It's not new, we were doing this 20 years ago at a company I worked at that produced cross platform code that ran on DOS, OS/2, Windows and Motif using the same binary.
http://www.gnustep.it/Renaissance/
According to the posting at AeroXperience, Carbon applications -- those build upon the Classic Mac OS programming interfaces -- can be embedded with Cocoa views under Leopard. Speculation is that this interoperability could provide applications like Photoshop and Microsoft Office access to advanced functions previously only available to Cocoa applications"
What does this actually refer to/ mean exactly?
Funnily enough, guess who is probably sending the largest (or second largest) contingent of developers to WWDC? I wonder how the developers from the MicroShaft Mac Business Unit understand the NDA. In theory, they should be absolutely forbidden from discussing secrets with anyone in the other units of the company! In reality, I'm sure Ballmer et al. come down and say, "Hey, guys, we just spent hundreds of thousands of dollars sending you to WWDC. What did you find out?"
It is my hope the despicable leaker and corporate sponsor can be identified by Apple and thoroughly trounced.
Fonts should be described in standardized print point sizes, not pixels. So that would make the display more like printers, when someone buys a higher dpi printer, they don't expect that the printed image is half the intended size. That and when someone choses a larger system font for easier readability, without resolution independence, it breaks a lot of controls as the text gets cut off.
Not true for web design ...
Font size should ALWAYS BE IN PIXELS for control of the look of a page, make a CSS for print using points - thats what it is for. Points are for printers only. This is easy typography 101 stuff. If you want to make is so people can use there own font size and do not care about how the page is rendered use EM's.
Every screen renders pixels the exact same size, points and EM's are rendered different from system to system and monitors.
EDIT here is a good resource : http://webdesign.about.com/cs/typeme.../aa042803a.htm
Every screen renders pixels the exact same size
From the link I posted:
"if control over the look of your Web page is your biggest concern, then you should use pixels. Pixels are the standard unit of measure for screens and monitors, and fonts will be more precisely the size you want on the screen."
From the link I posted:
"if control over the look of your Web page is your biggest concern, then you should use pixels. Pixels are the standard unit of measure for screens and monitors, and fonts will be more precisely the size you want on the screen."
My point was that pixels are not always the same size. If you use pixels in your webpage, yes, you know that the layout can't get borked and the relative positions of everything will always be the same, no matter what resolution it is viewed in. But, the higher the resolution of the screen, the smaller the content. This is what resolution independence is for: maintaining relative positions etc. but keeping everything at a readable size whilst allowing for high-detail imagery.
My point was that pixels are not always the same size. If you use pixels in your webpage, yes, you know that the layout can't get borked and the relative positions of everything will always be the same, no matter what resolution it is viewed in. But, the higher the resolution of the screen, the smaller the content. This is what resolution independence is for: maintaining relative positions etc. but keeping everything at a readable size whilst allowing for high-detail imagery.
Yes however using Points or EM will break your design no matter what. Fonts rendered in Pixels will always be rendered the same size in proportion to images and other elements. I do not see how using Points will work better than Pixels in resolution independence.
Ideally any resolution independence would look at the font size and enlarge it or shrink it the same way it does images.
He's not going to say, "there are some things we're keeping close to our vest so our friends up North don't start their copiers just yet" and then the same day hand everyone a DVD containing any of those features.
These are just things that weren't deemed headline important enough to hit the top 10 demos.
The real top secret things won't be on Leopard Preview until they are no longer top secret. I'm guessing things like a revamped Finder, an app that could more or less just appear later on without affecting developers use of the OS X APIs, which is why they need Leopard now.
Yes however using Points or EM will break your design no matter what. Fonts rendered in Pixels will always be rendered the same size in proportion to images and other elements. I do not see how using Points will work better than Pixels in resolution independence.
Ideally any resolution independence would look at the font size and enlarge it or shrink it the same way it does images.
12 points implies 12 pixels at 72 DPI. 12 pixels implies 12 pixels at any DPI.
So, a user with a 200 DPI screen of the future will need phenomenal eyesight to read a 12 pixel font—it will only be 1.5mm. They'll have no problem reading the 12 point font type which'll be 4.23mm.
I don't think you understand resolution independence very well....
In all likelihood, since the web ISN'T coded for resolution indendence, it'll scale pixels anyway, though.
Brando from "On the Waterfront".
I claim my ten points, which I exchange for a fully specced out Mac Pro, at the current points exchange rate.
You're smarter than you look.