• 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: Posting to NotificationCenter from an Open Source app
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Posting to NotificationCenter from an Open Source app


  • Subject: Re: Posting to NotificationCenter from an Open Source app
  • From: Fritz Anderson <email@hidden>
  • Date: Thu, 29 Jun 2006 13:35:06 -0500

On 26 Jun 2006, at 6:56 AM, Matthew Egan wrote:

I want to change an Open Source ftp server program to contact NSDistributedNotificationCenter and post a notification.

I want to add a couple of lines of code to tell another application that it has received a file and the download is complete. There are several examples on how to use NSDistributedNotificationCenter within a Cocoa app - but I want to send this notification from within a CLI application that is written in C. I would have to add the code and then make/compile with GCC.

Is this possible?

This is possible, with constraints you may not want in an open-source tool.


The tool must link against Foundation.framework.

The tool must have at least one Objective-C file that makes the notification. You can front it with a C API, so the rest of the tool doesn't have to know about the Objective-C part.

If the tool is expected to _receive_ a distributed notification, it must run an NSRunLoop (or its CF equivalent?) to connect to the notification mechanism. Your windowed application comes with a run loop for free.

Add a Foundation target to the windowed application's project, and drag all the tool's source in, attaching all of the newly-imported source to the Foundation target.
- or -
Have a separate Xcode project build the tool, include that project in the windowed app's project.


Make the app target dependent on the tool's product.

These last two steps may seem counter to the idea of using make for the tool, but
1) Xcode is easier, if you don't need to keep the makefile valid.
2) Even if you don't want Xcode for the tool, building the tool once with Xcode will give you a build transcript you can use as a crib for your makefile. Cocoa builds can be intricate.


If you're only building with Xcode for the information, remove the dependency on the tool target.

Make sure the tool itself — the product file — is included in the Copy Bundle Resources phase. (Better yet, put it into a new Copy Files phase with a destination of "Executables.")

I could go into more detail, but I am trying to be less encyclopedic these days.

However... another thing: You can build the tool with an Xcode external target. It will use the tool's makefile to manage dependencies.

	-- F

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Posting to NotificationCenter from an Open Source app (From: Matthew Egan <email@hidden>)

  • Prev by Date: _NSKVODeallocateLog
  • Next by Date: Re: NSImage bug? NEF Files.
  • Previous by thread: Posting to NotificationCenter from an Open Source app
  • Next by thread: objectForKey:self
  • Index(es):
    • Date
    • Thread