macOS Should I use Cocoa?

OK. Here's the background. I've got a old program XLISP that I want to bring up to snuff on OS X. You can look at the link, but basically it originally was a command-line program that needs a console/terminal for its user interface. The original version had graphics capability -- keep in mind this was under MS-DOS. In the early 90's I ported it to Windows 3.1 and later to Win 95 by creating a console window that I could also draw to. Crude but effective. No framework on top of the basic Windows system calls were used. The program is 100% C and a lot of the code is pre ANSI C as well.

Back to the present. Which of these approaches would make the most sense under OS X? Or is there an approach that I'm missing that's better? I basically have no Cocoa programming experience, but lots of general experience and experience in Java (which is not suitable for what I'm trying to accomplish).

1. A Cocoa solution using Objective-C but linking in the original C code. Create a console window just like I did before.

2. As in (1) but window has a one-line text box widget to type in commands and a multi-line text widget to display console output. My guess this would be considerably easier to accomplish than (1) but would it be acceptable?

3. Run from a Terminal window (which it currently does) but launch a GUI window that graphics can be drawn in. Frankly, I don't even know if this is possible (it wasn't in the MS Windows world), or if it would be upsetting to users, but it sounds like the easiest approach.

4. Forget about learning Cocoa and instead write using the Qt framework, doing one of the above three solutions. Advantage being I'd get a Linux and a modern Windows implementation for "free".

Thoughts?

I wouldn't mind learning Cocoa. My concern about Qt is would it end up being a second rate application, not integrating well into the Mac way of things? Java apps suffer that way.

balamw said:

Could you tolerate the overhead of using BSD sockets as an inter-process channel between the interpreter and the graphics process?

Click to expand...

Yes. I'm strongly considering at least a multi-threaded approach with all the programs computations being done on a separate thread from the user interface.

Hmmm. Well as it turns out I'll be needing to write a Qt app for Linux at work, so I think I'll take the easy way out and use a Qt window for graphics in an otherwise console application. I could probably whip that out in a few hours. I'll consider other options if that proves to be complete garbage.

Thinking more about sockets, it is doable, and I also have an alternate top level of the program that allows calling the LISP interpreter with expressions to evaluate, rather than using the built-in terminal interface. Both of these approaches could be used, but I'd be concerned that either of them would lose the tightness of the existing interface. I'm much more likely to use separate threads for the user interface and execution engine. That's the approved approach for modern GUI apps anyway, and one that I do all the time in Java. My older Windows XLISP didn't do this because Windows back then didn't have threads (or multitasking for that matter!).