• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Carbon API with carbon
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Carbon API with carbon


  • Subject: Re: Carbon API with carbon
  • From: Finlay Dobbie <email@hidden>
  • Date: Sun, 14 Jul 2002 12:41:09 +0100

On Sunday, July 14, 2002, at 12:12 PM, Ondra Cada wrote:

The question, clearly and unequivocally cited in my message which you followed, read:

Just wondering if there is any problems with using any of the carbon API's from a Cocoa application.

Therefore...

Just wondering if there is any problems with using any of the carbon API's from a Cocoa application.
Short of polluting your sources by a quite ugly
Nathan Day referred to an Obj-C wrapper for Process Manager, so this argument is void.

...there was no question of using this or that ObjC wrapper, but of using *CARBON API*, repeat, *CARBON API*.

I might have been confusing threads in my brain. Still, if you really want, you could write an Obj-C wrapper around any particular Carbon API you choose, and therefore confining the pollution to your wrappers where it's in no danger of polluting the rest of your sources.

and non-portable code,

Cocoa code isn't really portable, so this argument is void.

With some care, it is. See GNUStep.

I know about GNUstep. GNUstep isn't really a viable solution for most people. I can't say I have seen many commercial or shareware or even freeware Cocoa applications that are available for OS X and Win32 and/or Linux. If you want portable code, use a cross-platform GUI framework like Qt (or, these days, PowerPlant which is available for Win32 IIRC), which will be C++ and built on Carbon. Or use Java. Or write a highly portable, C-only core and have different GUI implementations for each platform.

I maintain that Cocoa isn't really portable. OK, so it might be in theory, but the reality is that Apple killed YellowBox for Windows and GNUstep doesn't have enough manpower.

...and there was again absolutely no question (and thus *no* hint from my side either) of using anything remotely alike to process management and/or AppleScript and/or whatever similar to "loading myself into all Cocoa applications system-wide" (which, incidentally, is not an "ugly hack" the slightest bit, but that would be, as Kipling says, another story).

I refer you back to your own words:

On Saturday, July 13, 2002, at 01:45 PM, Ondra Cada wrote:

Just send the appropriate NSApplication the appropriate message. If AppleScript is designed well (which I dunno at all), it should be possible through it. Otherwise, you need to load your own bundle into the application to do so (eg. via InputManagement) to get "inside".

I think you've lost me here?

-- Finlay
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • GNUStep and Cocoa Portabilitiy (Re: Carbon API with carbon)
      • From: Marcel Weiher <email@hidden>
References: 
 >Re: Carbon API with carbon (From: Ondra Cada <email@hidden>)

  • Prev by Date: Strange NSInvocation behavior when passing pointers
  • Next by Date: Re: Strange NSInvocation behavior when passing pointers
  • Previous by thread: Re: Carbon API with carbon
  • Next by thread: GNUStep and Cocoa Portabilitiy (Re: Carbon API with carbon)
  • Index(es):
    • Date
    • Thread