Andreas Klöckner wrote: > On Samstag 13 Juni 2009, you wrote: >> Andreas Klöckner wrote: >>> (Resend from subscribed address) >>> >>> On Mittwoch 10 Juni 2009, Ian Ward wrote: >>>> Andreas Klöckner wrote: >>>>> While I'm at it, two questions for Ian: >>>>> >>>>> - I'd love to be able to replace the hardcoded sys.stdout in >>>>> raw_display. Would you take a patch? (This would allow me to implement >>>>> an option to hijack sys.stdout. This would get rid of the annoying >>>>> flicker on every program execution step.) >>>> I encourage patches. If it's general and useful I might even apply it >>>> :-) >>> Attached. Let me know what you think. >> A couple questions: >> >> Can you think of a use case for setting one of term_output_file, >> term_input_file but not the other? If not I would put them together as >> a single parameter. > > Can't think of one. > >> What are the usage instructions for this interface? What streams are >> you likely to want to pass in for term_output_file and term_input_file? > > Funnily, sys.stdout and sys.stdin. The point is that I want to hijack > sys.stdin and sys.stdout to capture what goes into and out of them--I just > need Urwid to keep referring to the un-hijacked ones. > >> Andrew Psaltis is working on something similar that we have been >> discussing on IRC. Just attaching stdin/stdout to something else isn't >> enough. We also need to have a program running on that secondary >> terminal that will catch resize events and send them back to the >> application. > > Good point--but not an issue for the above use case. :)
Ah, that makes sense. How about we just save sys.stdin and sys.stdout when we create the screen (same as your code, just without the __init__ parameters) then someone can change them to whatever they want after creating the screen? Ian _______________________________________________ Urwid mailing list [email protected] http://lists.excess.org/mailman/listinfo/urwid
