I have not used glut for any OS X based projects, but my impression is that if you intend to use no OS facilities in the window you are interacting with then glutKeyboardFunc() and friends should work just fine. If you want to use a WebView or anything that expects NSEvents in that window you are probably going to find it much more complicated. Instead of just consuming the incoming NSEvents you want and passing on the rest you will need to synthesize NSEvents for anything you want to pass on.
In general mixing and matching event models is a lot more pain than it is usually worth. If you are going to write a pure OpenGL based application then glut will probably serve you well, if you intend to use any Cocoa facilities (such as WebKit) you are going to have to work with the native event system at some point along the way, and I suspect converting glut style events into something the rest of the stack can use is a lot more (platform specific) code than just extracting what you want from the NSEvents in the first place. Louis On Tue, Jun 17, 2008 at 9:28 PM, Josh de Lioncourt <[EMAIL PROTECTED]> wrote: > Hi Louis and Andy, > > I'm certainly looking at this suggestion, but another developer suggested > that I may be better served by hooking into the keyboard input functionality > of OpenGL. Assuming that have focus on an NSWindow doesn't interfere with > such an implementation, I'd be able to accomplish the input through a > non-platform specific API, potentially making my code even more portable > between Windows and OS X. > > Is there any reason why I shouldn't consider OpenGL for input? > > > Josh de Lioncourt > Mac-cessibility: http://www.Lioncourt.com > Twitter: http://twitter.com/Lioncourt > > > "The rich declare themselves poor, > "And most of us are not sure, > "If we have too much, > "But we'll take our chances, > "'cause God stopped keeping score." > Praying for Time--George Michael > > > > > On Jun 17, 2008, at 5:03 PM, Andreas Monitzer wrote: > >> On Jun 18, 2008, at 01:22, Louis Gerbarg wrote: >> >>> It sounds like what you want to do is here is subclass NSApplication, >>> with a replacement implementation of sendEvent that decodes the >>> incoming events, marshals the NSEvent's parameters, then sends them to >>> your C++ code for processing. If your C++ code uses them you swallow >>> the event, if not you pass it onto the superclasses implementation and >>> the app code will handle them just like any other Cocoa application. >> >> Note that this is just what I did for the X-server: >> >> >> http://www.google.com/codesearch?hl=en&q=monitzer+show:Nu3rlWhknBM:x28_xYSo3mE:b82DNfVvtyQ&sa=N&cd=1&ct=rc&cs_p=http://gentoo.osuosl.org/distfiles/X430src-3.tgz&cs_f=xc/programs/Xserver/hw/darwin/quartz/XApplication.m >> >> This can serve as an example on how to implement something like this. Just >> don't forget to declare this subclass to be the principal class of the >> application bundle. >> >> andy > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/lgerbarg%40gmail.com > > This email sent to [EMAIL PROTECTED] > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
