Re: GPM mouse tracking issues solved, kindof

The attached patch seems to work, and was really easy to add. My only question is should 'real' events get priority? Right now, gpm events get flushed first - will this screw up anything?

Ben Wing <ben(a)666.com&gt; writes: > I didn't receive it twice, but I don't care about receiving things twice > in any case. > > But you shouldn't be doing what you're doing. The event-stream code has > many places that assume that only specific types of events (i.e. not > mouse motion events) are on the command-event queue. We could modify > such code to allow for this possibility, but it seems as though you might > run into the "excessive numbers of motion events" problem -- i.e. if > XEmacs is very slow and behind in processing events, the queue could fill > up with large numbers of GPM motion events. With X or MSWIN, this won't > happen because XEmacs won't ask for an event until it's ready for one, > and X and MSWIN won't generate mouse events until they're requested. > > So I think the cleanest way would be to do exactly what Jan proposes -- > don't try to stuff your events at all; instead, create your own queue for > motion, button, and all other GPM events, and put wrapper functions > around the next-event and event-pending-p callbacks. > > When you do this, however, make sure you grep through the code for all > places that might change these callbacks -- I have a vague feeling that > in some cases (e.g. some debug-enabled code?), the callbacks might get > changed in the middle of a running XEmacs. It doesn't look like anybody (but me now) changes event_stream once it is created. The attached patch seems to work, and was really easy to add. My only question is should 'real' events get priority? Right now, gpm events get flushed first - will this screw up anything? The only thing that doesn't work right now is multiple GPM-aware devices within the same running XEmacs. I tried to get this working, but multiple calls to Gpm_Open don't seem to work. My basic approach was going to be: 1) gpm-enable would call Gpm_Open 2) If it succeeded, it would create the subprocess object 3) reset global gpm_fd to -1 4) reset global gpm_tried to 0, so that Gpm_Open will retry opening its supposedly 'dead' socket. 5) reset gpm_fd just before the Gpm_GetEvent() call in Freceive_gpm_event by grabbing the input fd from the process object, and set it back to -1 afterwards. Some of the internal caching that Gpm_Open does screws this up, I'm not sure why. I'm going to call this good enough for now. If I can get ViaVoice running on my desktop or my laptop I might start playing around with converting that to the connect_to_file_descriptor() method of things. Anybody played with ViaVoice OutLoud yet? You could make a speech synthesizer for EmacsSpeak that didnt' require a separate synthesizer. You could hook right into redisplay... -Bill P.