Comment # 109 on bug 1054448 from Dr. Werner Fink

(In reply to Egmont Koblinger from comment #101)

> 
> > [1]Otherwise it would be never possible to develop new features for XTerm
> > supported by the TERMINFO entry xterm or xterm-256color
> 
> This isn't solved for xterm itself either, assuming that users might ssh
> across systems. The whole approach with the TERM variable referring to a
> local file, and then only this variable getting forwarded across ssh is a
> broken concept. IMO it's way beyond the scope of this bugreport to design,
> let alone implement and adopt something better.

ncurses 6.1 has a new 32bit format for e.g. xterm-256color and if konsole can
not read this do not using libtinfo then this is not a bug of ncurses.
If a user or the system setup uses xterm-256color even if it is known that a
remote system can not handle this as xterm-256color is not known then this is
also not a bug for ncurses

(In reply to Wolfgang Bauer from comment #108)
> (In reply to Tad Bilby from comment #107)
> > It looks like the xterm-256color terminfo file is the issue.
> > $ infocmp
> > infocmp: couldn't open terminfo file /usr/share/terminfo/x/xterm-256color
> > # zypper in terminfo
> > No update candidate for 'terminfo-6.1-1.1.x86_64'. The highest available
> > version is already installed
> > $:/usr/share/terminfo/x> file xterm-256color
> > xterm-256color: Compiled 32-bit terminfo entry "xterm-256color"
> > $:/usr/share/terminfo/x> file xterm
> > xterm: Compiled terminfo entry "xterm"
> 
> That seems to be normal.

Does konsole read any information from an terminfo entry specified by the TERM
variable? If this is done (xterm does it) how this is done? If onw code in
konsole or the QT/KDE libraries does this, then the question rises if this code
can handle 32bit terminfo entries?  The libtinfo 6.1 can handle this extend
format