Future of Carbon vs Cocoa?

[JazzMan]

I noticed that the Apple online documentation has marked all Carbon functions to be "Deprecated". They push hard to move all development to Cocoa and there were rumours that it would be removed from 10.5. It wasn't removed though. What will happen if OSX 10.6 no longer contains support for Carbon?
(Apple has a tradition to remove backward compatibility once a while, unlike Windows, which is of course also the reason why OSX runs so smooth)

I don't know how close Carbon and Cocoa are to each other? - but I suppose it will take some time to make a Lazarus-Cocoa implementation, which means applications made for Carbon will not work for new Macs until the Cocoa implementation has finished... in years...?

Best regards,
Hans

[Phil]

I noticed that the Apple online documentation has marked all Carbon functions to be "Deprecated". They push hard to move all development to Cocoa and there were rumours that it would be removed from 10.5. It wasn't removed though. What will happen if OSX 10.6 no longer contains support for Carbon?
(Apple has a tradition to remove backward compatibility once a while, unlike Windows, which is of course also the reason why OSX runs so smooth)

I don't know how close Carbon and Cocoa are to each other? - but I suppose it will take some time to make a Lazarus-Cocoa implementation, which means applications made for Carbon will not work for new Macs until the Cocoa implementation has finished... in years...?

Hi Hans,

Could you post the links for what you refer to above?

Currently, if you removed Carbon from OS X, the latest versions of the following apps would no longer work:

-Safari
-QuickTime
-FireFox
-iCab
-TextWrangler
-Adobe Reader
etc.

While most apps on the Mac are now "cocoa-based", most also link against the Carbon framework. Some, like Adobe Reader, are still Carbon-only apps. In fact, looking through the apps on my Mac I could only find one app that was pure Cocoa without any dependency on Carbon.

Certainly a Cocoa-based widgetset for Lazarus would be nice to have one day, but let's use the Carbon-based one for now and get it working as well as possible. Tomas has pretty much finished the Carbon widgetset but further testing and bug reporting by lots of Mac programmers would still be very helpful.

Perhaps you could investigate what would be necessary to create Cocoa bindings for Free Pascal. Currently the Carbon widgetset references functions defined in FPCMacOSAll.pas in /usr/local/share/fpcsrc/packages/extra/univint. Something analogous to this unit would be needed for the Cocoa framework.

Thanks.

-Phil

[felipemdc]

Currently, if you removed Carbon from OS X, the latest versions of the following apps would no longer work:

I'm on the Apple newsgroups and there has never been mentioned such a thing as removing carbon. What happens is that they decided to make Carbon a 32-bits only library. They won't release a 64-bits version of the GUI parts of Carbon.

The future is going to Cocoa, but it's not our fault that Apple made such a horrible move, so we will take our time to move.

Almost everything cross-platform out there uses Carbon, like Microsoft Office, wxWidgets, Tk, because it's much better to make cross-platform software with it.

Perhaps you could investigate what would be necessary to create Cocoa bindings for Free Pascal.

We already have them. Or at least 1% of them. I've already managed to make a simple gui app purely in Pascal linking to Cocoa using bindings I created manually. I will soon publish on a public subversion.

Unfortunatelly I have no knowledge of creating parsers, so it's all manually done. Help from someone that can create a parser that reads the objc headers and automatically generate the Pascal bindings (which are object oriented by the way =) ) would be great.

[Phil]

The future is going to Cocoa, but it's not our fault that Apple made such a horrible move, so we will take our time to move.

I'm not sure if I would characterize it quite like that. Carbon is a holdover from the pre-OS X days and is probably quite large. The FPCMacOSAll.pas interface unit alone is over a quarter million lines long, so you can imagine the size of the code behind it. Not moving an older procedural API like Carbon to 64-bits doesn't seem unreasonable to me.

A procedural C API certainly does make cross-platform work easier at first for those programmers who have no Objective C experience, but moving to a purely OO API might be better in the long run for everyone.

Certainly Apple has big plans for OS X. Not only does it run on both PowerPC and Intel-based desktops, but it also is used in the iPhone, iPod Touch and the AppleTV devices. With a Cocoa-based widgetset and the right compiler for these devices' processors we could conceivably create native apps for them as well as for newer devices that Apple will inevitably release.

Thanks.

-Phil

[felipemdc]

A procedural C API certainly does make cross-platform work easier at first for those programmers who have no Objective C experience, but moving to a purely OO API might be better in the long run for everyone.

The problem goes way beyond sintax. It isn't that horrible because using the obj-c runtime headers we can make a direct bridge between Object Pascal and Objective-C, unlike C++ where one needs to procedurize the API.

But, the way Cocoa was designed, it's completely improductive and inadequate to cross-platform development. It's simply not planned to be used purely by code without using their NIB files and Xcode, and it's a hell of a job to make a Cocoa app that doesn't require those things (even in objc), and something completely undocumented by Apple.

You have to relly on hacks and third-party blogs about those hacks to get it working.

Certainly Apple has big plans for OS X.

Maybe, but I think that having such a horrible backwards compatibility is shooting itself on the foot. Personally I would never recomend OS X on a company just because and exactly because of their bad backwards compatibility.

People don't want to recode their apps that work great for no good reason other then the Apple executives think Cocoa is cool. That are no technological obstacles preventing a 64-bits Carbon port. They simply don't want to do it.

[Phil]

It's simply not planned to be used purely by code without using their NIB files and Xcode, and it's a hell of a job to make a Cocoa app that doesn't require those things (even in objc), and something completely undocumented by Apple.

People don't want to recode their apps that work great for no good reason other then the Apple executives think Cocoa is cool. That are no technological obstacles preventing a 64-bits Carbon port. They simply don't want to do it.

.nib files are just XML, so maybe these get created automatically from .lfm files similar to the way .lrs files are created by lazres because FPC can't handle embedded .lfm file resources.

The .nib file is central to OS X's localization so I'm not sure you would want to avoid them altogether.

Don't forget that your 32-bit Carbon apps will still run fine. You don't have to recode them.

Thanks.

-Phil

[felipemdc]

(very initial) Wiki page about the Cocoa bindings:

http://wiki.lazarus.freepascal.org/PasCocoa

[Phil]

(very initial) Wiki page about the Cocoa bindings:

http://wiki.lazarus.freepascal.org/PasCocoa

Looks like you've been busy and the C bindings. Good work!

Thanks.

-Phil

[JazzMan]

Good to see that so many applications still rely on Carbon. Then Apple will hopefully not remove the support for Carbon for some time. I was a little to quick to conclude that Carbon was deprecated in the reference. It was only a few sections, which were the ones I happened to see, where this was the case. In those cases the functionality seemed to be replaced by a newer approach.

It is much better to combine our resources to make the Lazarus-Carbon implementation complete rather than dividing them into a Carbon and a Cocoa division. At least at this time. It is great that the Carbon widgetset has come this far!

Best regards,
Hans

[Phil]

Good to see that so many applications still rely on Carbon.

Hi Hans,

I suspect that what the developers of many of these Cocoa-Carbon hybrids are doing is using Cocoa for the user interface, which is probably really what Apple is pushing, and still using some of the many, many general purpose functions in Carbon for non-UI stuff.

I believe Apple also has a Java interface, which programs like NeoOffice use, so I think I can understand why they might want to cut back on Carbon, at least for the user interface stuff, which they're always advancing to stay ahead of everyone else. Making sure all of the new user interface functionality works identically across 3 API's might be a pretty big challenge.

Thanks.

-Phil

[skalogryz]

Hi everyone!

I think 'proceduring the API' is quite good solution, and it's the one recommended by Apple:
http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html

This reference is useful primarily for developing bridge layers between Objective-C and other languages, or for low-level debugging. You typically do not need to use the Objective-C runtime library directly when programming in Objective-C.

I guess using this API to access Objective-C objects would not be slower, than using native Objective-C. I have not yet tested this myself, but everything looks quite nice, though A LOT OF WORK to be done!
I just hope this routines would be also available at iPhone...

sekel:
I have some experience in writing parsers, and i'd like to help with writing cocoa-pascal bindings

[Phil]

I guess using this API to access Objective-C objects would not be slower, than using native Objective-C. I have not yet tested this myself, but everything looks quite nice, though A LOT OF WORK to be done!
I just hope this routines would be also available at iPhone...

sekel:
I have some experience in writing parsers, and i'd like to help with writing cocoa-pascal bindings

Remember that the Obj-C API is not the same as Cocoa.

Thanks.

-Phil

[felipemdc]

Looks like you've been busy and the C bindings. Good work!

Thanks =)

I suspect that what the developers of many of these Cocoa-Carbon hybrids are doing is using Cocoa for the user interface, which is probably really what Apple is pushing, and still using some of the many, many general purpose functions in Carbon for non-UI stuff.

Well, actually no. It's a little bit complex to deal with this with so many overlapping concepts, ok, let me try to simplify stuff:

* Carbon AppKit - The GUI part of Carbon
* Cocoa AppKit - The GUI part of Cocoa
* Foundation - All non-gui part of both of them

Apple is just dropping "Carbon AppKit". It's not dropping the non-visual part of Carbon and those parts (CoreGraphics, Foundation, etc) are indispensable to both Cocoa and Cocoa applications.

Those lot's of applications based on Carbon (Microsoft Office, Photoshop, Tcl/Tk, Finder, etc) are actually using the Carbon AppKit with some small portions of Cocoa to do some stuff that isn't available througth Carbon, and thus they will be heavely affected. Their GUI part will need to be rewritten.

I believe Apple also has a Java interface....Making sure all of the new user interface functionality works identically across 3 API's might be a pretty big challenge.

Java is not a separate interface, it's just something built on top of the other stuff.

Like we have LCL working on top of Carbon they made a Java implementation on top of Carbon and then moved it to Cocoa.

[felipemdc]

sekel:
I have some experience in writing parsers, and i'd like to help with writing cocoa-pascal bindings

That would be great =) Take a look at the PasCocoa code and compare with the original files, most of them on /Library/Frameworks/Appkit.Framework/Headers/ (or something similar)

We need a parser that can receive some inputs and convert the files based on them. The input would be:

1 - List of files to be converted
2 - For each file tell which methods are constructors

[felipemdc]

I think 'proceduring the API' is quite good solution, and it's the one recommended by Apple:
http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html

That's exactly how my Cocoa bindings work, althougth I think that the term "proceduring the API' to be wrong, because:

1 - The bindings don't make anything that wasn't procedural become procedural.

2 - There is already a technique of building headers with that name and it has nothing to do with what is done for the objc-pascal bridge.