Re: Bug#1053963: RFS: termpaint/0.3.0-3 [RC] -- low level terminal access - headers
On Sun, Oct 15, 2023 at 02:23:28AM +0200, Salvo Tomaselli wrote:
> Could you improve the description?
I think we are open for improvements, although ideally not in an upload
that fixes an RC (and future FTBFS) bug.
Do you mean the short description or the longer one?
Because with libraries i find i really hard to have something really useful
in the short description. Even the rough subject area hardly fits. And with
libraries in the end you have to either install them because of
dependencies or you really want to look deeper.
>
> What does this do?
It has a "no io" part that takes bytes the application passes it from a
terminal and outputs bytes to be routed to a terminal and on the other
side offers an interface for the application to receive decoded input
events and to write text/symbols to the internal cell buffer and send
updates of that buffer to the terminal.
Plus the usual terminal mode setup helpers for mouse modes, alt screen etc.
If you happen to want to use the kernel tty interface for communication it
also has a optional part that does the whole write, tcsetattr, select and
friends.
Also if you bring your own event loop you might want to only use parts of
that support.
Otherwise you could also hook it up directly to libssh or whatever you
want. (it has a utility application that shows how libssh could be used).
>
> For me low level access is ioctl, write or similar…
Well i don't think there is a universal mapping what low level means in the
terminal space. Termpaint can (optionally) use those calls, or if the
application needs more control the application can do those.
But what i think makes termpaint a low level library is that it really just
does terminal interfacing. It doesn't have any kind of windows, panels,
widgets, controls or even an opinion how things should look.
e.g. it offers thin abstractions over all the usual ways to have colors in
a terminal (none/default, 16 colors, 256 colors (it does not assume that
the low 16 of the 256 are exactly the same as the 16 colors) and 24bit
(direct) color.
It's up to the application to pick which one to use. It does have some
(application switchable) down sampling, and offers some clues if the
24 bit color mode is supported by the terminal. Or if the 256 color mode
is likely just a 88 color mode.
So i guess you can see how this is mostly low level. For example ncurses
offers a lot more out of the box. But i think it is useful to have
something that is unopinionated in how the application wants to use the
terminal.
But this kind of detail is way to much for even the long description of a
debian package.
What do you think is missing in the long description that still fits
within the contraints of a sensible package description?
>
> Best
>
> --
> Salvo Tomaselli
>
> "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
> senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
> -- Galileo Galilei
>
> https://ltworf.codeberg.page/
Reply to: