Python TUI that will work on DOS/Windows and Unix/Linux

J

James Harris

Am looking for a TUI (textual user interface) mechanism to allow a Python
program to create and update a display in text mode. For example, if a
command prompt was sized 80x25 it would be made up of 80 x 25 = 2000
characters. The Python program would need to be able to write to any of
those 2000 characters at any time though in practice the display would
normally be arranged by dividing it up into non-overlapping rectangular
regions.

I have seen that there are various libraries: urwid, newt, console, dialog
etc. But they seem to be either for Unix or for DOS, not for both. I am
looking for a library that will run under either.

Furthermore, some libraries are complex, providing widgets of all kinds. I
am looking for something much simpler and the lighter-weight it is the
better. At least at this stage I pretty much just want to divide the screen
up into panels.

Input from keyboard would be essential. Input from a mouse would be nice to
have.

Especially if you have had a similar requirement in the past but even if
not, is there any cross-platform system you would recommend?

James
 
J

James Harris

James Harris said:
Am looking for a TUI (textual user interface) mechanism to allow a Python
program to create and update a display in text mode. For example, if a
command prompt was sized 80x25 it would be made up of 80 x 25 = 2000
characters. The Python program would need to be able to write to any of
those 2000 characters at any time though in practice the display would
normally be arranged by dividing it up into non-overlapping rectangular
regions.

I have seen that there are various libraries: urwid, newt, console, dialog
etc. But they seem to be either for Unix or for DOS, not for both. I am
looking for a library that will run under either.

In case anyone else is following this, people have emailed me directly
suggesting ncurses, pdcurses and these:

Pygcurse (http://inventwithpython.com/pygcurse/)
UniCurses (http://sourceforge.net/projects/pyunicurses/)

Naturally, all of these are centred on curses. I have been reading up on it
and must say that the whole curses approach seems rather antiquated. I
appreciate the suggestions and they may be what I need to do but from what I
have seen of curses it was designed principally to provide common ways to
control cursor-based terminals. That was a-la-mode in the days when we had
terminals with different cursor control strings and I remember programming
VT100 and VT52 monitors or terminals like them. But now it seems cumbersome.

I haven't thought too much about it so this is not a design proposal but it
might be better to divide a display up into non-overlapping windows and
treat each one separately. Writes to one would not be able to affect the
others. A given window could allow writes to fixed locations or could behave
as a glass teletype, writing to the bottom of the window and scrolling as
needed, or could behave as a viewing port into a data structure. Something
like that may be more useful to a programmer even if it has to use curses
underneath because that's all that the OS provides.

James
 
M

Michael Torrie

Naturally, all of these are centred on curses. I have been reading up on it
and must say that the whole curses approach seems rather antiquated. I
appreciate the suggestions and they may be what I need to do but from what I
have seen of curses it was designed principally to provide common ways to
control cursor-based terminals. That was a-la-mode in the days when we had
terminals with different cursor control strings and I remember programming
VT100 and VT52 monitors or terminals like them. But now it seems cumbersome.

Well it's the same problem you're trying to solve today. You've got a
text console with a cursor you can move around and print out text.
Besides with any modern operation system you can't write directly to the
screen anyway, like we used to back in the DOS days when we poked
directly into video memory.
I haven't thought too much about it so this is not a design proposal but it
might be better to divide a display up into non-overlapping windows and
treat each one separately. Writes to one would not be able to affect the
others. A given window could allow writes to fixed locations or could behave
as a glass teletype, writing to the bottom of the window and scrolling as
needed, or could behave as a viewing port into a data structure. Something
like that may be more useful to a programmer even if it has to use curses
underneath because that's all that the OS provides.

A toolkit (that's old, arguably), that might help you is TVision, a port
of the old Turbo Vision library that formed the foundation for Borland's
old DOS IDEs back in the day (check wikipedia). And it looked quite
beautiful back then, actually. There is a Python binding for it here:

https://pypi.python.org/pypi/PyTVision

The original C++ is here:
http://tvision.sourceforge.net/

TVision does run on DOS, Windows console, and of course Unix, though
you'd need the appropriate shared library.

Or you could write your own, based on top of something like curses.
 
J

James Harris

....
A toolkit (that's old, arguably), that might help you is TVision, a port
of the old Turbo Vision library that formed the foundation for Borland's
old DOS IDEs back in the day (check wikipedia). And it looked quite
beautiful back then, actually. There is a Python binding for it here:

https://pypi.python.org/pypi/PyTVision

That looks very good.

For the record, I have been emailed about npyscreen and urwid. And I have
found a hex editor with the kind of interface I had in mind. Here are some
links for anyone else who is interested.

http://www.sigala.it/sergio/tvision/images.html
http://www.npcole.com/npyscreen/
http://excess.org/urwid/examples.html
http://www.hexedit.com/hex-edit-shots.htm

James
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,961
Messages
2,570,131
Members
46,689
Latest member
liammiller

Latest Threads

Top