2 Replies
      Latest reply on Feb 4, 2019 4:07 AM by Sheppy
      Sheppy Level 1 Level 1 (0 points)

        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?

        • Re: Sharing a UI across multiple one-window processes
          eskimo Apple Staff Apple Staff (11,495 points)

          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.

          Making a window from app A appear as if it’s in app B is not really feasible on the Mac [1].  In contrast, converting app A to a headless process that renders data and passes the results back to app B to display in one of its windows should be feasible.

          Doing this inefficiently is just a simple matter of IPC.  The trick is doing it efficiently, and that will require you to learn about IOSurface.  That’s somewhat outside of my area of expertise, so I can’t offer any specific pointers, but some searches for that keyword will turn up a bunch of info.

          Share and Enjoy

          Quinn “The Eskimo!”
          Apple Developer Relations, Developer Technical Support, Core OS/Hardware
          let myEmail = "eskimo" + "1" + "@apple.com"

          [1] The OS can do this, but it’s using a whole raft of internal stuff that you don’t have access to.