[nylug-workshop] Fwd: [nylug-talk] [Reminder] Regular meetings of the Python workshop @ Tue Dec 5 6pm - 8pm

[Dan Crosta]

err, whoops...meant this for the workshop list

- d


Begin forwarded message:
> From: Dan Crosta <dcrosta at sccs.swarthmore.edu>
> To: NYLUG Technical Discussion <nylug-talk at nylug.org>
> Subject: Re: [nylug-talk] [Reminder] Regular meetings of the Python  
> workshop @ Tue Dec 5 6pm - 8pm
>
> On Dec 4, 2006, at 6:51 PM, Peter C. Norton wrote:
>> At this week's workshop, we'll be looking at trying to understand the
>> dtk CursesEngine input handling, and trying to either reproduce it to
>> better determine how it works in an isolated example, or add logging
>> to the CursesEngine to find out more about what's being received by
>> dtk when it doesn't (seem to) properly handle inputs.
>
> It might not be that worth trying to understand or recreate the  
> behavior of the current input routines in curses engine -- the only  
> important behavior it has is to translate keys (however the input  
> is represented, and on that score I think Peter's method wins for  
> clarity) into the user friendly strings, eg:
>
>   <user presses page up> => <dtk program sees 'page up'>
>
> That said, if you do try to recreate the behavior as it currently  
> stands, it might be worth going a slightly different route: rather  
> than having the keymap class variable and curmap instance variable  
> references, it might be simpler and clearer to have just the keymap  
> nested dict and an accumulator list of seen input. the behavior  
> would then be, every time parseInput() is called walk through  
> keymap using the values accumulated input values. then, if this  
> results in traversing keymap to a leaf node (ie a string value),  
> return that and remove from the accumulator input that was  
> consumed; if it runs out of the keymap, then this is a key keymap  
> doesn't know about; and if it ends up somewhere in between return  
> none and wait for more input to be added to the accumulator. this  
> has the advantage of allowing the possibility to queue input for  
> later consideration, for instance in a threaded application.
>
> - d