nanogui: Re: Ideas on Nano-X event handeling and API (was: Re: Nano-X on X )
Subject:
Re: Ideas on Nano-X event handeling and API (was: Re: Nano-X on X)
From:
Morten Rolland ####@####.####
Date:
29 Nov 1999 16:02:54 -0000
Message-Id: <3842AFEC.4B4F403C@screenmedia.no>
Hello,
Greg Haerr wrote:
> I think I missed your original point about what you're trying to do.
> Basically, I'll restate it here. What you want is to allow Nano-X to be used
> in applications where, instead of modelling the application around Nano-X's
> event loop, you call some Nano-X functions from your application, and
> the Nano-X gui functionality works. This is what you called a "passive"
> library approach.
Yes, indeed -- this is what I would like!
> Basically, all this requires is that some of the sections of Nano-X's
> main loop be placed in procedures, and those procedures be callable
> as a standard API. The application then has it's own main loop and
> select(). This should be fairly easy. Following your suggestion, the
> following routines could be created:
>
> GrPrepareSelect() - prepare Nano-X fd_set and timeout values
> GrServiceSelect() - service Nano-X fd_set fd's or timeouts
> GrDoSelect() - perform Nano-X select (not used for your
> stuff)
Bulls eye! Yes, this would be just perfect... This would enhance the
flexibility
and suit my needs like a hand in a glove. I assume the GrDoSelect is a call
you
make inside the Nano-X client library when you do use the main-loop
functionality
provided with Nano-X?
> I believe that, as you mentioned, the GrRegisterInput should remain (enhanced
> for multiple file descriptors) as the standard method of adding file descriptors
> to Nano-X when used as an active library.
Yes, keeping the old method is smart for backward compatibility, but it also
makes it possible to write nice applications that builds on top of Nano-X
entirely (but may still be a slave to a custom main loop). I like this a lot!
> I'll add these routines in the next cut, which I expect to get out this weekend.
Wow. I didn't really expect the idea to catch on that fast... :-) I figured
they
would be best implemented together with the new async Nano-X protocol. I'm
looking
forward to this!
Thanks a bundle,
Morten Rolland
