From: Ethan M. <merritt@u.washington.edu> - 2004-10-22 16:45:04
|
On Friday 22 October 2004 12:24 am, Per Persson wrote: > > I seems to me that the driver will have to duplicate the main event > loop and take over control while mousing is active. > > I'm reluctant to have an opininon where I don't intend to put down > work, but wouldn't it be cleaner to have a single event loop and an > event queue where any input unit (keystrokes at the prompt, mouse > clicks etc.) put their events to be processed by the event loop in a > timely manner? That is the way it works now for x11 and ggi, yes. The driver provides a routine (*term)->waitforinput() that merges the input stream from the keyboard and from the plot window[s]. Events pulled from this merged input stream are either handled by the caller, e.g. interpret new command line, or by the mousing code, e.g. do_event() in mouse.c. > By making events (i.e. their structure) device independent at the level > of the main loop/event queue the drivers would only have to translate > an event as it is recieved and could then forget about it. Yep. That's the idea, and the core code is already in place. It's just that up until now not many of the drivers actually use it. But it sounds to me that most of the work in adding mousing to aquaterm would consist of (1) providing an AQUA_waitforinput() routine, and (2) implementing the terminal-specific draw commands for mouse-coordinate printout and rulers (optional). The rest of it, including hot-keys and zooming, should "just work". > An any case, this is not something I have strong opinions about and in > case anyone feels like working on providing event support for the > aquaterm driver I'd gladly provide as much help as I can. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |