Jan-Philip Gehrcke wrote: > Hey urwid list! > > I am planning a commandline application with a special design and would > like to know if urwid is the module I need to realize this :-) > > The structure of the application I imagine: > > 1) the "endless loop part": > --------------------------- > A background thread permanently runs and checks a web service let's say > every X seconds. Depending on what it sees and on special user-given > parameters it makes some decisions and runs this, this or that > function/code. During this endless process, some stdout is produced to > log to the terminal what's happening.
You can run a separate thread/process then put messages in a queue for the interface to display. You will need to either poll that queue from the interface thread/process or set up your event loop to handle message arrival - the SelectEventLoop in the development version can do this for you. > > 2) the "deterministic part": > ---------------------------- > The user should be able to interact with the application using a prompt > where he can enter special commands by typing "command + ENTER". When he > presses ENTER, the command is processed by the deterministic part of the > application; the "user-input-processing-part" so to say. This starts > some special code, e.g. changing some variables, running some functions > and -- of course -- producing some output to stdout, too. The code > invoked by entering a command is deterministic (not an endless loop, no > endless stdout). > > Regarding the prompt and displaying stdout I would like to have the > following behaviour: > - the prompt is one line fixed on the screen (let's say on the bottom) Use a Pile or Frame to separate the screen into a scrolling part and a command part. > - Before pressing ENTER, the user should be able to move through what > he's typed by pressing the arrow keys and to delete what he has typed > by pressing backspace. Actually, I just would like to have the same > behaviour as e.g. raw_input() has. the Edit widget does this. > - all stdout should just grow up as in a common terminal, but just one > line higher: above the prompt. The output of part 1 and 2 may mix up; > I don't care at the moment. > - The application must definitely support scrollback to scroll through > what has been written to stdout. The best thing would be, if the > default scrollbar of e.g. KDE konsole or Gnome terminal will work to > scroll. Is that realistic? If that does not work, does urwid support > scrolling by mousewheel or by a scrollbar that is dragged with the > mouse? In case that the normal scrollback of the Terminal is not > supported: how much scrollback (how much lines) does urwid support / > is realistic without crashing the application? Is there an easy way > to cut it somewhere (I think one should care for it not to grow to > infinity) the ListBox is for vertically scrolling text. The terminal scroll bar only works if the program is allowing lines to scroll off the screen. Urwid doesn't currently do that. There is no standard scroll bar widget in Urwid at the moment, but there is one in the contributed examples. If you're happy to use your terminal's scroll bar, why don't you just use stdout and raw_input? You can probably make the input refresh itself when new output is displayed somehow. If you will ever need something more complicated, or less likely to garble the terminal then Urwid would be a better choice. Ian _______________________________________________ Urwid mailing list [email protected] http://lists.excess.org/mailman/listinfo/urwid
