I am working on updating an existing single-window OpenGL Mac application to support multiple open windows. Each window would be running the same code but with different data. There are a lot of global variables and structures involved in managing the state of the original application, so if I can keep each window's memory space separate, I can avoid having to basically rewrite all the original code practically from scratch. Bonus points if I can find a solution that lets the windows be grouped and ungrouped using the window tab APIs.
In addition to the instance windows, there will need to be a preference window and assorted other UX features, along with the main menu bar (which would need a list of the instances as well, of course).
To that end, I'd like to do something more or less like the following:
- Create an encapsulating application that provides the main menu bar, global preferences, and UX for creating, loading, saving, and otherwise managing the individual windows that contain instances of the main application.
- Revise the existing application to migrate all its UX code out to the new encapsulating app, leaving just the core code that processes the data and draws the graphics using OpenGL into its view.
- Doesn't matter to me whether the instance windows are created by the encapsulating app and the instances send their frames to the window buffer using shared memory or the like, or the instances create their own windows. I would think the latter is the easiest and smartest way to go. The only reason I leave open the possibility of having the encapsulating app create the instances' windows is that it might make the interactions between the instances and the Cocoa UI code easier.
While this could be done by just having each instance have its own menu bar and dispatching messages back and forth to keep menus in sync and such, but it would not look very clean and seems like a pretty messy solution. I'm hoping there's a better way. Any ideas?