Multiple document application with 'game-like' documents?

Apologies for a terse post, I somehow became logged out while typing much the same thing in just now and have lost my original...

I am attempting to create a multiple document application in which each document is 'game-like', by which I mean that I want my model to have key up/down events coming in and an OpenGL view going out. These views will normally be contained in windows, but the user may optionally make one or more of them full screen. For the purposes of my view, this is a full Cocoa application.

So far I've done this:

• created a custom view that inherits from NSOpenGLView but enables anti-aliasing (Interface Builder still being broken in recording the anti-aliasing properties set for NSOpenGLViews) and adds the necessary methods so that the view is willing to become first responder and hence to receieve keyUp and keyDown; and
• added code so that when the user wishes to take a window into full screen mode, CGDisplayCapture is used to capture the screen containing the majority of that window (and that screen only), a new borderless window is created in front of the resulting shielding window with the correct proportions and the content view from the normal, bordered window is transferred to the borderless window. The normal window is kept around and the content view transferred back if the user exits full screen.

As a preamble style question, is this somewhere where it is considered a good idea to subclass NSOpenGLView? I'm mindful that in Cocoa, subclassing is usually not the answer but it seems that neither NSOpenGLView or NSWindow are willing to pass keyboard events to a delegate and my main view code is a derivative of NSDocument. I guess an alternative would be a custom view below the OpenGLView that doesn't draw anything; would there be any advantages or disadvantages to either approach that I may not have considered?

My main question concerns the means by which I am transferring to a full-screen display. It seems that the window I programmatically create does not receive keyboard events. My diagnosis is that probably the default window controller is routing those events to the bordered window that is no longer visible? I've tried [[currentWindow windowController] setWindow:newWindow] (with currentWindow retained, in case the user wishes subsequently to exit full-screen mode), with no effect.

Firstly, is this an acceptable way to implement this sort of functionality? If so, what can I do to ensure that the borderless window is able to receive keyboard events? If not, what alternative approach should I be taking?