nanogui: small misc. feature patch for nanox and flnx
Subject:
Re: small misc. feature patch for nanox and flnx
From:
Gary James ####@####.####
Date:
22 Apr 2001 14:59:40 -0000
Message-Id: <20010422110012.A775@pc.twcny.rr.com>
Steve,
You ought to post the patches. Otherwise it could be months before anybody
gets a chance to see your fixes.
Gary James
####@####.####
http://home.twcny.rr.com/embedded/
On Sat, 21 Apr 2001 23:12:24 Steve Hein wrote:
> Greg,
>
> I am using flnx and nanox (under Linux) in a situation where I am linking
> the nanox server directly into the app. That worked fine, but I
> found that when I used Fl::add_fd() to get input on file
> descriptors or sockets, I would never get them. Basically,
> this is because GrGetNextEvent() was called to get mouse/keyboard
> events but its select() loop didn't watch for the file descriptors
> I gave to flnx via Fl::add_fd().
>
> My solution was to:
> - added a configure option, --with-microwinlink, to tell flnx
> when nanox server is linked into app (enables my features)
> - fix GrRegisterInput() to allow multiple file descriptors
> - add a GrUnregisterInput() to remove descriptors
> - have flnx call GrRegisterInput() and GrUnregisterInput()
> when add_fd() and remove_fd() are called (ONLY when
> configured with --with-microwinlink)
> - have GsSelect() create GR_EVENT_TYPE_FDINPUT events
> (when NONETWORK is set) for events on any FD's that
> were registered via GrRegisterInput()
> - have fl_handle() check for GR_EVENT_TYPE_FDINPUT events
> and call the appropriate callbacks
>
> Granted, there are still issues here:
> - seems like Fl::add_fd/Fl::remove_fd can't work when the nanoX
> server isn't linked (since the fl_handle() loop basically just
> loops on waiting for X events, I think...)
> - this only covers input (read) events as I implemented it
>
> But, it seems like this is an improvement, and the way I
> added it seems like it shouldn't affect cases that don't
> use it.
>
> If you'd like the 2 patches (one for flnx-0.16, one for
> microwindows-0.89pre7), let me know where I should send them.
> (They're not too big, but I didn't know if I should post
> the patches directly to this list).
>
> Steve
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
