On Dec 7, 2014, at 4:42 PM, Keary Suska <cocoa-...@esoteritech.com> wrote:
> On Dec 7, 2014, at 1:35 PM, SevenBits <sevenbitst...@gmail.com> wrote: > >>> >>> I don't know if this approach is more likely to work in a sandboxed app. I >>> doubt it, because it would be an enormous hole in the sandbox. If you can >>> direct Terminal to run arbitrary commands, what protection does the sandbox >>> provide? >> >> I get your point, but the fact is, I’m not trying to run an arbitrary >> command, and I don’t even care if Terminal inherits the sandbox from my >> process. I just need to run this command in a window so that the user can >> type input in and receive the results back. In other words, I’m looking for >> Terminal’s user interface, not its ability to run arbitrary commands. >> >> If it matters, the executable is a program that evaluates instructions using >> REPL (read-eval-print loop). >> >>> >>> >>>> I really need this to work as it’s an important aspect of my application. >>>> Can anyone advise? >>> >>> I suspect you have a serious problem, then. You will probably need to >>> deploy outside of the Mac App Store so that you don't have to sandbox your >>> app. Alternatively, you can build a terminal emulator UI into your app and >>> run the embedded console program within that, instead of Terminal. >>> Depending on the needs of your console program, that may be a relatively >>> straightforward prospect or a very complex one. >> >> Well, I’m stuck in the middle. On the one hand, implementing a full-brown >> terminal emulator along the lines of iTerms 2 for my app is overkill and >> isn’t worth the extra megabytes. But I don’t want to implement a kludgy >> NSTextField-based interface to feed in input using NSTask and output/input >> streams either, as it doesn’t look that great. >> >> However, unless someone can come up with a good way to provide a >> Terminal-like environment for REPL applications, the second approach is the >> one I’ll probably have to take… > > I would first try NSTextView instead--you get a lot of control simply from > delegate calls, although you will need to subclass. The only tricky part is > how to handle the parts that would not be editable, and what to do when > someone tries to edit it. Setting a custom attribute is probably the way to > go. The TextViewDelegate sample app shows how to handle that _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
