On Sep 19, 2012, at 9:05 PM, Zak Nelson wrote: > At a high level, I'd like to share an NSView between processes.
That's not a high level. That's a pre-determined implementation approach, which is at best mid-level. You should really rethink this. As stated – "share an NSView between processes" – it's not possible. Even on a more abstract level, it's generally not the way things are done. Why do you think you need/want to do this? You're not developing for Windows, so don't try to develop like you would for Windows. There are very few legitimate reasons to do something like this. Web browsers do when they host plug-ins in separate processes, but that's because they're running foreign code and there are security and stability implications. > ... I'm hiding my subprocess' view and using the IOSurface APIs > (http://developer.apple.com/library/mac/#documentation/Miscellaneous/Reference/IOSurfaceAPI_header_reference/Reference/reference.html) > to get the bitmap back into the parent process. Transferring images (bitmaps) between processes is a somewhat higher level task and IOSurface is well-suited to doing that quickly. > The problem I'm having now is in sending mouse events to the subprocess' > view. Calling [NSApp sendEvent] from the subprocess, the events don't arrive, > which I guess is because the application is not in the foreground. I've also > tried using CGEventPost which requires the view to be visible and the API > moves the mouse, two non-starters. Based on this research it appears > impossible to send mouse events to views without key focus. You need to get your thinking unstuck. It's not impossible to send mouse events to views without focus. Surely, you've clicked on a button in a window where focus was on a text field. But more simply, you can always invoke -mouseDown: directly, if you so choose. But even then, what would your (presumably custom) view do in response to a mouse click? Why not just put that in a custom method and invoke that. (The view's -mouseDown: override would also invoke that same thing.) As Mikevann suggested, If you really want to let a subprocess be responsible for the content of a view in a parent process, you should design a custom communication protocol. Use any of various IPC mechanisms to convey status, events (custom data structures, not NSEvent), and requests between the two processes and have the parent process carry out the actual rendering to the view on behalf of the subprocess. This would be similar to X11, for example, where the X server owns and does the actual drawing to the windows, while clients interact with the X server to drive the particulars of that process. > The next approach I've been considering, which is even more outlandish than > my current setup, is to overlay the subprocess' window on top of parent's > window. There are a number of edge cases I'm not keen on handling, and that's > assuming it's efficient enough to not look terrible. I'm not sure why think it's more outlandish. It _might_ make more sense. Anyway, the right place to start is: what are you actually trying to achieve? Don't answer with implementation (almost anything involving views, processes, etc.) approaches. Answer with end-user-visible behaviors. Regards, Ken _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
