Re: Bug#1053963: RFS: termpaint/0.3.0-3 [RC] -- low level terminal access - headers
On Sun, Oct 15, 2023 at 06:51:51AM -0400, Thomas Dickey wrote: > > Likewise, it uses xterm's documentation (and source code) extensively > (such as in termquery.cpp) without mentioning the source of the information. Yes, termquery.cpp is a testing helper shipped in the source that has the need to name modes. I mean where else would one get names for those than the only contemporary documentation of those things. Which is the xterm documentation. Yes, i should not have assumed that it's totally obvious to anyone in the space that those things are either from some floating around DEC manuals or from ctlseqs. I'm happy to fix that with a link back to your site, as it really is one of the best sources. But that files is not even linked into the library so it's a bit of a tanget wrt termpaint itself. For the rest, i don't think there is a lot that is similar to xterm except as technically needed (e.g. the details of the 256 color color map) But in the end this whole project is based on careful study¹ (and redocumentation) of a lot of terminal implementations including xterm, so some things might have stuck in my mind. I'm happy to look into any other places where you feel that attribution is missing. But this is all quite of topic here, so let's take that to private mail or to the upstream issue tracker. Regards, - Martin ¹ which even lead me to report some improvments to xterm some years ago.
Re: Bug#1053963: RFS: termpaint/0.3.0-3 [RC] -- low level terminal access - headers
On Sun, Oct 15, 2023 at 04:51:47AM -0400, Thomas Dickey wrote: > On Sun, Oct 15, 2023 at 02:23:28AM +0200, Salvo Tomaselli wrote: > > Could you improve the description? > > > > What does this do? > > > > For me low level access is ioctl, write or similar… > > no - in this case "low level" is a synonym for "hard-coded" > > It's just another of the programs written with the assumption that the > terminal is xterm (or one of its imitators). Well the long description clearly states that it only focuses on "terminals in the tradition of VT1xx (like xterm, etc)". It does make vastly different choices in terminal support than termcap and ncurses. That allows is to have a more direct mapping of the terminal functions but of course, it does not support nearly the breadth of terminals that ncurses can support. But i think that is ok, as many users nowadays use terminals in the supported set. Another choice where it differs is the it is build with the reality in mind that $TERM is much more likely to be blatently wrong that than it having to work with a terminal that is not "xterm like". Thus is uses terminal response fingerprinting and terminal self identification to decide what terminal implementation it is likely talking to and then uses its internal (hard coded) terminal information to select features and workarounds. Yes. That is throwing the towel on expecting properly administrated systems, but a varity of factors ends making properly administrated systems to be on the decline. > > Unlike the last one on this topic, it uses the terminology of ncurses > without using the word "ncurses". I'm not sure what you mean with the terminology of ncurses, mostly because ncurses certainly defined a lot of the terminology of the field and thus it's hard to say where something is ncurses (or curses) specific or just the broader terminology with terminals. And i think the debian package is not really the place for a detailed discussion of the tradeoffs between say ncurses and termpaint. Or termpaint and s-lang or ... They would need a lot of nouance, and i'm pretty sure i would get it wrong. So i think it is better to be silent on that than to offer something incomplete. As you pointed out, it is not even a alternative to ncurses, because it has a vastly smaller set of supported terminals. - Martin
Bug#1030307: RFS: posixsignalmanager/0.3-2 -- posix signal handling for qt
[upstream here] On Thu, 2 Feb 2023 16:13:41 +0100 Norwid Behrnd wrote: > > So long for a library, change the name. I don't see why library may not have a descriptive name instead of a short and cryptic one. And the debian package name follows the name of the library it contains. Which is by its pkg-config name: PosixSignalManager Yes, some may find that ugly and long, but it's the libraries name, and discussions on if that name is good should be held upstream. I'm not aware of any debian policy the package name might violate. Also this is a upload to package that recently entered testing but did not build for various release architectures due to tests build on amd64 centric assumptions, which should now be fixed. I think it's important to try to help debian to offer packages on as many architectures as feasable. > > It might be better to rename the package after bookworm became stable. > Given how near we are in the release cycle to the freeze for new packages to enter testing i agree that **if** the name needs changing it is more feasable to do that targeting bookworm+1, but i still think that the name is fine.
