cocoaforge

This is an interesting rumor:

http://www.macrumors.com/pages/2005/12/ ... 3900.shtml

If this pans out, and all of Cocoa is ported to Windows for free, including webkit, what do you think the odds are of a Windows version of Adium?

I personally would never need it, since I haven't even used Windows in years, but the possibility of it all is certainly interesting...

I would certainly not hang my hat on it. This rumor has been debunked by several sources, most notably Wil Shipley (co-founder of OmniGroup, developer of Delicious Library)

Speculation is fun, but the odds of it are small and the thing to keep in mind is that it adds another wrinkle for developers: PowerPC versus Intel Macs being one wrinkle, Cocoa/Mac versus Cocoa/Win being another. I don't see Apple introducing this kind of hassle in a move that wouldn't do anything to truly increase their marketshare.

Take home point: would any substantive forces of the software industry (Mac or Win) move their codebase to Cocoa to insure cross-compatibility? No. Beyond obvious reasons, it would effectively be a new API, and no one would move en masse to something untested, unproven, and with no business impetus.

The other problem is all the Carbon code we use

bgannin wrote:This rumor has been debunked by several sources, most notably Wil Shipley (co-founder of OmniGroup, developer of Delicious Library)

Got a link?


On top of that, any Quartz rendering is probably not gonna work anyway. (Not that I know exactly how much Adium relies on that)

Catfish_Man wrote:The other problem is all the Carbon code we use

I'll go on record saying that if Apple actually ports the Cocoa frameworks to Windows, I will personally remove every bit of Carbon code in Adium and replace it with shiny Cocoa code.

I seriously doubt I'll have to make good on that promise, but there it is

David Munch wrote:

bgannin wrote:This rumor has been debunked by several sources, most notably Wil Shipley (co-founder of OmniGroup, developer of Delicious Library)

Got a link?


On top of that, any Quartz rendering is probably not gonna work anyway. (Not that I know exactly how much Adium relies on that)

http://wilshipley.com/blog/2005/12/silly-season.html

Adium does not, to my knowledge, explicitly use Quartz, and I don't know that a movement of Cocoa would affect Quartz if it did, as Apple would likely emulate a lot of those calls with bridge code to Windows-specific drawing APIs to allow the calls to continue, just not with their Mac-like speed.

Brings up the excellent point though: if you port Cocoa (i.e., AppKit + Foundation) you need to bring along most [if not all] supporting frameworks and technologies (Quartz, WebKit, PDFKit, QTKit, DiscRecording, etc.) Imagine the overhead of such an undertaking, then find a way to justify it - in business terms, not "I love Apple. I love Cocoa. Windows should die."

bgannin wrote:

David Munch wrote:

bgannin wrote:This rumor has been debunked by several sources, most notably Wil Shipley (co-founder of OmniGroup, developer of Delicious Library)

Got a link?


On top of that, any Quartz rendering is probably not gonna work anyway. (Not that I know exactly how much Adium relies on that)

Adium does not, to my knowledge, explicitly use Quartz, and I don't know that a movement of Cocoa would affect Quartz if it did, as Apple would likely emulate a lot of those calls with bridge code to Windows-specific drawing APIs to allow the calls to continue, just not with their Mac-like speed.

Actually we call directly into CG for the contact list gradients (it's still slow, but not as much). It'd be simple enough to just #ifdef in a non-CG version for x86 though, even if they didn't bridge CG.

We could always wait for GNUStep too…

bgannin wrote:This rumor has been debunked by several sources, most notably Wil Shipley (co-founder of OmniGroup, developer of Delicious Library)

Not only has he no idea of what Apple's doing, but it is just opinion.

Kiel :-)

bgannin wrote:

David Munch wrote:

bgannin wrote:This rumor has been debunked by several sources, most notably Wil Shipley (co-founder of OmniGroup, developer of Delicious Library)

Got a link?


On top of that, any Quartz rendering is probably not gonna work anyway. (Not that I know exactly how much Adium relies on that)

http://wilshipley.com/blog/2005/12/silly-season.html

Adium does not, to my knowledge, explicitly use Quartz, and I don't know that a movement of Cocoa would affect Quartz if it did, as Apple would likely emulate a lot of those calls with bridge code to Windows-specific drawing APIs to allow the calls to continue, just not with their Mac-like speed.

Brings up the excellent point though: if you port Cocoa (i.e., AppKit + Foundation) you need to bring along most [if not all] supporting frameworks and technologies (Quartz, WebKit, PDFKit, QTKit, DiscRecording, etc.) Imagine the overhead of such an undertaking, then find a way to justify it - in business terms, not "I love Apple. I love Cocoa. Windows should die."

Read your Kochan book, you can use foundation on multiple platforms as it is. That leaves qtkit (qt is already ported), appkit and a few others. Might not be *as* hard as some make it out to be, but still, don't see it happening.

Oh, and if this happens, it'd make porting Growl to Windows a hell of a lot easier

The_Tick wrote:

bgannin wrote:

David Munch wrote: Got a link?


On top of that, any Quartz rendering is probably not gonna work anyway. (Not that I know exactly how much Adium relies on that)

http://wilshipley.com/blog/2005/12/silly-season.html

Adium does not, to my knowledge, explicitly use Quartz, and I don't know that a movement of Cocoa would affect Quartz if it did, as Apple would likely emulate a lot of those calls with bridge code to Windows-specific drawing APIs to allow the calls to continue, just not with their Mac-like speed.

Brings up the excellent point though: if you port Cocoa (i.e., AppKit + Foundation) you need to bring along most [if not all] supporting frameworks and technologies (Quartz, WebKit, PDFKit, QTKit, DiscRecording, etc.) Imagine the overhead of such an undertaking, then find a way to justify it - in business terms, not "I love Apple. I love Cocoa. Windows should die."

Read your Kochan book, you can use foundation on multiple platforms as it is. That leaves qtkit (qt is already ported), appkit and a few others. Might not be *as* hard as some make it out to be, but still, don't see it happening.

Oh, and if this happens, it'd make porting Growl to Windows a hell of a lot easier

Well If you want to be technical you could also stub out certain specific calls and attempt to just GNUStep's AppKit [as your lowest common denominator] with ifdef's for OS X specific sections and accomplish a fair chunk of the stated goals now [as was briefly mentioned a few posts back]

Also, stating Cocoa (AppKit + Foundation) wasn't a misnomer. While Foundation runs on multiple platforms, Cocoa would not, and the entirety would need to work and the commonality discussed was Cocoa, not the finer grain portions

*nit-picking done, time for Christmas party*

EDIT: additional ports - CoreData, bindings technology, a system-level mapping for user defaults [falls under AppKit], SyncServices, DotMacKit... (and as previously noted in this edit, underlying tech. (like the Truth database for syncing) and their dependencies)

Foundation is easier to make so portable because it is so insular, whereas the rest of the frameworks that fall directly under Cocoa or indirectly in its development environment are more specific and demanding [as well as more substantial]