Re: Rethinking my approach; rather overwhelmed.
Re: Rethinking my approach; rather overwhelmed.
- Subject: Re: Rethinking my approach; rather overwhelmed.
- From: "Louis Gerbarg" <email@hidden>
- Date: Wed, 18 Jun 2008 01:29:12 -0700
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@hidden> 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 (email@hidden)
>
> 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:
>
> This email sent to email@hidden
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden