FROM : Sherm Pendley
DATE : Sun Mar 23 22:35:14 2008
On Sun, Mar 23, 2008 at 5:08 PM, Carsten <<email_removed>> 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--
DATE : Sun Mar 23 22:35:14 2008
On Sun, Mar 23, 2008 at 5:08 PM, Carsten <<email_removed>> 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--
| Related mails | Author | Date |
|---|---|---|
| Carsten | Mar 22, 23:26 | |
| Tom Harrington | Mar 22, 23:36 | |
| Carsten | Mar 23, 00:01 | |
| Marcus | Mar 23, 06:46 | |
| Carsten | Mar 23, 09:10 | |
| Marcus | Mar 23, 09:31 | |
| Carsten | Mar 23, 09:43 | |
| Brian Stern | Mar 23, 18:35 | |
| Carsten | Mar 23, 22:08 | |
| Scott Ribe | Mar 23, 22:16 | |
| Sherm Pendley | Mar 23, 22:35 | |
| Carsten | Mar 23, 22:43 |






Cocoa mail archive

