Mailing List Archive

> On 21 Apr 2023, at 22:00, Grant Edwards <grant.b.edwards@gmail.com> wrote:
>
> ?I recently googled across the ncurses application framework npyscreen,
> and was thinking about giving it a try for a small but real project
> (something that would be distributed to customers), but I'm a bit
> concerned that npyscreen no longer "alive".
>
> The pypi page says the homepage is http://www.npcole.com/npyscreen/,
> which then points to a Google Code page at https://code.google.com/archive/p/npyscreen/.
>
> That page says the official repo is at https://bitbucket.org/npcole/npyscreen
> which returns a 404.
>
> There seems to be a copy in Github at https://github.com/npcole/npyscreen/commits/master,
> but the last commit was almost 4 years ago.
>
> Maybe it "just works" and is suitable for production?

Maybe this, recently lwn.net article, https://textual.textualize.io/
I was planning to check it out.

Barry
>
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list

On 4/21/2023 5:57 PM, Barry wrote:
>
>
>> On 21 Apr 2023, at 22:00, Grant Edwards <grant.b.edwards@gmail.com> wrote:
>>
>> ?I recently googled across the ncurses application framework npyscreen,
>> and was thinking about giving it a try for a small but real project
>> (something that would be distributed to customers), but I'm a bit
>> concerned that npyscreen no longer "alive".
>>
>> The pypi page says the homepage is http://www.npcole.com/npyscreen/,
>> which then points to a Google Code page at https://code.google.com/archive/p/npyscreen/.
>>
>> That page says the official repo is at https://bitbucket.org/npcole/npyscreen
>> which returns a 404.
>>
>> There seems to be a copy in Github at https://github.com/npcole/npyscreen/commits/master,
>> but the last commit was almost 4 years ago.
>>
>> Maybe it "just works" and is suitable for production?
>
> Maybe this, recently lwn.net article, https://textual.textualize.io/
> I was planning to check it out.

It's still pip-installable from PyPi.

--
https://mail.python.org/mailman/listinfo/python-list

On 4/21/23 15:57, Barry wrote:
> Maybe this, recently lwn.net article, https://textual.textualize.io/
> I was planning to check it out.

Textual definitely looks slick and modern. And with a modern terminal
emulator it works quite well and is responsive. I'd definitely consider
it for a TUI.

But on the Linux console, or on an older terminal, not so much.
Textual's really designed for smallish unicode fonts in a windowed
environment, not any kind of real, old-school text mode. Just something
to keep in mind. 99% of terminal users are using a modern terminal
emulator these days, with full color and unicode, which is the target of
textual.

Curses-based programs don't look great on anything, but they do look
consistent on more primitive terminals.
--
https://mail.python.org/mailman/listinfo/python-list

On 2023-04-24, Michael Torrie <torriem@gmail.com> wrote:
> On 4/21/23 15:57, Barry wrote:
>
>> Maybe this, recently lwn.net article,
>> https://textual.textualize.io/ I was planning to check it out.
>
> Textual definitely looks slick and modern. And with a modern
> terminal emulator it works quite well and is responsive. I'd
> definitely consider it for a TUI.
>
> But on the Linux console, or on an older terminal, not so much.
> Textual's really designed for smallish unicode fonts in a windowed
> environment, not any kind of real, old-school text mode. Just
> something to keep in mind. 99% of terminal users are using a modern
> terminal emulator these days, with full color and unicode, which is
> the target of textual.

Is putty running on Windows a "modern terminal emulator" in this
context? After observing some of the local IT types work, I suspect
that will be a common use-case for the app I'm working on.

> Curses-based programs don't look great on anything, but they do look
> consistent on more primitive terminals.

The other big advantage of an ncurses program is that since curses
support is in the std library, a curses app is simpler to distribute.
Right now, the application is a single .py file you just copy to the
destination machine and run. It supports command-line use and a Tk
GUI. I can add an ncurses "CUI" without having to either adopt a more
complex bundling mechanism that requires it to be "installed" or
require that users install dependencies via pip/apt/yum/whatever.

--
Grant
--
https://mail.python.org/mailman/listinfo/python-list

On 2023-04-24, Grant Edwards <grant.b.edwards@gmail.com> wrote:

> The other big advantage of an ncurses program is that since curses
> support is in the std library, a curses app is simpler to
> distribute. Right now, the application is a single .py file you
> just copy to the destination machine and run. It supports
> command-line use and a Tk GUI. I can add an ncurses "CUI" without
> having to either adopt a more complex bundling mechanism that
> requires it to be "installed" or require that users install
> dependencies via pip/apt/yum/whatever.

However... I just realized that Python's curses support is missing two
huge chunks: both menu and form support are not there. I guess that
explains why people feel the need to write high-level UI wrappers for
Python curses: the high level stuff that curses does support is
missing from the Python bindings.

Adding a curses UI for my app might not be feasible after all...

--
Grant

--
https://mail.python.org/mailman/listinfo/python-list

On 4/24/23 10:32, Grant Edwards wrote:
> On 2023-04-24, Grant Edwards <grant.b.edwards@gmail.com> wrote:
>
>> The other big advantage of an ncurses program is that since curses
>> support is in the std library, a curses app is simpler to
>> distribute. Right now, the application is a single .py file you
>> just copy to the destination machine and run. It supports
>> command-line use and a Tk GUI. I can add an ncurses "CUI" without
>> having to either adopt a more complex bundling mechanism that
>> requires it to be "installed" or require that users install
>> dependencies via pip/apt/yum/whatever.
>
> However... I just realized that Python's curses support is missing two
> huge chunks: both menu and form support are not there. I guess that
> explains why people feel the need to write high-level UI wrappers for
> Python curses: the high level stuff that curses does support is
> missing from the Python bindings.
>
> Adding a curses UI for my app might not be feasible after all...
>
> --
> Grant
>

I guess it's also worth mentioning that Python curses doesn't work out
of the box on Windows - because the actual curses library isn't commonly
present on Windows. It's not hard to get hold of builds (check PyPI) but
that means it's no longer "standard".




--
https://mail.python.org/mailman/listinfo/python-list

On 2023-04-24, Mats Wichmann <mats@wichmann.us> wrote:
> On 4/24/23 10:32, Grant Edwards wrote:
>
>> However... I just realized that Python's curses support is missing two
>> huge chunks: both menu and form support are not there. I guess that
>> explains why people feel the need to write high-level UI wrappers for
>> Python curses: the high level stuff that curses does support is
>> missing from the Python bindings.
>>
>> Adding a curses UI for my app might not be feasible after all...
>
> I guess it's also worth mentioning that Python curses doesn't work out
> of the box on Windows - because the actual curses library isn't commonly
> present on Windows. It's not hard to get hold of builds (check PyPI) but
> that means it's no longer "standard".

That's a good point. I neglected to mention that the use case for
curses UI app is to run on headless Linux servers. It needs to work
when run on a Linux by a user logged in via Putty on Windows, but I
have no need to execute the application in curses-mode on Windows.

--
Grant



--
https://mail.python.org/mailman/listinfo/python-list

On 4/24/23 08:04, Grant Edwards wrote:
> Is putty running on Windows a "modern terminal emulator" in this
> context? After observing some of the local IT types work, I suspect
> that will be a common use-case for the app I'm working on.

Yes, Putty qualifies as a "modern terminal emulator." It supports UTF-8
and unicode fonts. And the mouse events work as well. The only catch
is the default font is courier new which seems to not have some of the
line drawing characters in it. But if I change to something like
Cascadia Code it looks very good.

--
https://mail.python.org/mailman/listinfo/python-list

On 4/24/23 09:14, Stefan Ram wrote:
> Grant Edwards <grant.b.edwards@gmail.com> writes:
>> The other big advantage of an ncurses program is that since curses
>> support is in the std library, a curses app is simpler to distribute.
>
> IIRC curses is not in the standard library /on Windows/. I miss
> a platform independent (well, at least for Linux, Mac, and
> Windows) package with curses features in the standard library.
>
>


That's correct (or was, last time I looked). For this reason, I
resorted to using tkinter for the twander file browser. While
it works, the code needs a complete rethink and to be written
to be Python3 compatible. Perhaps when/if that happens, something
like Textual need serious consideration.

tkinter works, but is showing its age. So a fresher look without
all the burden of X and or requiring a browser, while also giving
you that option is appealing.
--
https://mail.python.org/mailman/listinfo/python-list

On 4/24/23 11:32, Grant Edwards wrote:
> On 2023-04-24, Grant Edwards <grant.b.edwards@gmail.com> wrote:
>
>> The other big advantage of an ncurses program is that since curses
>> support is in the std library, a curses app is simpler to
>> distribute. Right now, the application is a single .py file you
>> just copy to the destination machine and run. It supports
>> command-line use and a Tk GUI. I can add an ncurses "CUI" without
>> having to either adopt a more complex bundling mechanism that
>> requires it to be "installed" or require that users install
>> dependencies via pip/apt/yum/whatever.
>
> However... I just realized that Python's curses support is missing two
> huge chunks: both menu and form support are not there. I guess that
> explains why people feel the need to write high-level UI wrappers for
> Python curses: the high level stuff that curses does support is
> missing from the Python bindings.
>
> Adding a curses UI for my app might not be feasible after all...
>
> --
> Grant
>


That's because the Gods Of Ancient Internets knew that all you
ever really need is VT220 escape sequences ... unless you
are one of the heathens that still program in HLLAPI on 327x
machinery .... (I kid, I kid, NO one needs that pain ...)

--
https://mail.python.org/mailman/listinfo/python-list