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

[Dan Crosta]

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