On Sun, Mar 23, 2008 at 5:08 PM, Carsten <[EMAIL PROTECTED]> wrote: > > Note that I am not planning to attack all this at once. I just want to > make sane choices up front about how things would be done, skeleton it > out, and then leave most of it for a later full implementation. I want > to start with the core engine and the Cocoa GUI. The initial overall > architecture should not be done later though. That might make it very > hard to accomplish cleanly, if at all.
An alternative that hasn't been mentioned yet is to put the core engine in a library. The Cocoa GUI would link against it, and include it in its .app bundle. The command-line tool would also be included in the the Contents/MacOS subdir, so as to allow the library's install_name (if it's a .dylib) to resolve correctly for both the command-line tool and the GUI app. You would, of course, want to create the symlink in /usr/bin as described earlier. Another possibility would be to write a tool that parses the command-line options, but doesn't do the "heavy lifting" itself. Instead, it could communicate with the .app by way of AppleScript, raw Apple Events, or some other IPC mechanism. One thing I would *not* do is try to write a single binary that attempts to provide both GUI and CLI interfaces. Horses for courses, and all that. :-) sherm-- _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
