[README.bugs] Before sending bug reports, first note that some programs have flaws when run under an X console. So rule number one is to check the "bug" with another X terminal to find out whether it is `konsole' specific or not. Installation problems: Please note that running the linux application requieres that the linux16x8 font is installed on your system. Since i have a strong personal dislike of requiering an installation to be run with root privileges, i've omitted this step from the installation script. See README.linux.console for an installation procedure that requiere root privileges. Alternativly, you can try doing the same using xset(1x) only. Following a list of problems known with some applications: MC (midnight commander 4.1.21): - only when the emulation is called 'xterm' mc reacts on resize events (before any key is pressed) and on (xterm) mouse events. Note that xterm mouse events aren't specific at all, e.g. the Linux console produces them also. - After ^O (showing the secondary screen) mc does not propagate resize events at all to it's sub shell. Try this with xterm, or whatever else terminal emulation. - Apparently it does more strange things with the sub shell. When resizing the window with the mc panels shown, the secondary screen gets somehow affected (by real or faked prompts). This gets even worse when an application program is running while doing so. - sends out at least newlines but often more stuff when resizing while the panels are shown. - Under high traffic, some parts of the text is known to get lost. Try `ripple' in the test directory until you notice a drop. Since i've been able to reproduce this bug with kvt, rxvt and xterm, and i validated also that the data is already lost at read(3), i may well have stumbled into something different here. Because i was also only able to produce this effect while running mc, i feel pretty certain that mc's subshell handling causes this effect. vim 4.6: - emits a newline at exit, thereby producing a strange image on the secondary screen when run together with mc as default editor. dselect (Debian package manager front end): - assumes black background. So turn to white-on-black color scheme when using it. Broken termcap and terminfo databases: Please be aware of the fact that most applications (those using ncurses) base their knowledge on how to talk to a terminal emulation on the information within a database. This might well be wrong. Again, you should experience likely problems then with other emulations. So, for example: - debian 1.3.1 (Bo) omits the kdch1 entry, thus the DELETE key does appear not to work properly. Other keys might be missing as well. - the mc 4.1.21 distribution contains a xterm.ti with faulty hpa, vpa entries (with `[' omitted after `\E'). Even stranger, xterm runs happily with them, because of a feature, that allows to accept errorness sequences under some circumstances (\E{digit}C is treated like \E[{digit}C, where C is a non-digit.). - I've included a xterm.ti for this reason. (Compiles it tic.) Problems with BACKSPACE, DELETE and likely keyboard issues. Once upon a time there was a terminal without a delete key. This problem has been perpetuated in Linux and is still a never ending nightmare. It has been worked around separately in all programs that have to deal with these keys and they have now ended up to be configurable and therefore are likely to come in configured wrong. And so is konsole. Konsole emits DEL (0x7f) for the BS key and ESC[3~ for the DEL key if the `BS sends DEL' option is activated, and then behaves like a typically configured Linux console. Ctrl-H (0x08) is then left for the use of the application programs, e.g. typically configured emacs help. When this options is not set, the BS key sends BS (0x08) and the DEL key sends DEL (0x7f), as regular VT100s and IBM PCs do. [ Since every program can be configured BS=BS, DEL=DEL, and the poor terminal without delete key mentioned above exists today only in legends, the author wonders why this BS hack is still around. ] ctrl-^ == ctrl-~ == ctrl-` == RS == 0x1e cannot be typed with an european keyboard map loaded, since all three base characters are prefixes (i.e. are eventually to be continued with a second character). X11 is known to have these dead keys. Color Scheme and Font Attributes - The colors have been chosen to match VGA, that is the appearance of the Linux character console. Therefore, the colors are gamma-corrected a little and appear more dim then the colors of xterm. - Dim yellow is brown for the same reason. - Apparently, not emulation used with Linux does carefully distinguishes between the BOLD and the INTENSIVE attribute. The later does not even exists. Thus, while bold means intensive on VT100 terminals, it is treated as a font attribute by xterm and rxvt. For strange reasons, both applications really treat bold as meaning bold+intensive. I found that looks weird, and hacked around it so that bold means intensive for all but the default colors, which are instead presented bold (and cannot be intensified). Although the rendition function is well able to handle bold and intensive separately, it appears that no agreed-on escape codes exists, that could be used to take these two orthogonal attributes apart. [I'm working on this.] Fonts - the VGA font uses a different encoding then the other ones, and will therefore not display graphic and national characters when run with TERM=xterm. It is best suited to dos(1) and also work somewhat with TERM=linux. Note that the inclusion of this font is experimental. - other fonts but the ones included appear not to be usable for terminal applications. This is not that much due to their variable pitch (which i'd implemented experimentally), but because they miss the graphical subset. Try xfd(1x) to check this. - In general a proper font family for terminals seems to be missing at all. If you know about a scalable terminal font family, please drop me a line. Known bugs (konsole-0.8.6) in order of importance - keys on the keypad does not cause any effect when numlock is not set. This truly reflects, what is received from QT. All that keys come in as #ffff (unknown). It's a QT (1.40) issue. One could work around this by X11. - The history buffer should only be maintained for one of the screens. - check TODO for "bugs" due to missing features, also. Security Although konsole is prepared to be installed root-suid, it is not intended to be used so. Don't do it. Konsole drops privileges immediately after being started. Secure keyboard is not implemented and konsole does not fchown(2) the pseudo tty. Features that will not be implemented. - utmp entries. The utmp is a database that reports who is currently logged on. This is used by programs like who, finger, wall, talk, etc. to list the users of a system and to contact them. It does not make sense when used with an X terminal, since there is nothing like _the_ terminal then, to which one can send notices. The proper solution would be, to stamp the utmp with the xdm/kdm session manager. Further, a proper notification/chat program should be run automatically when the X session starts (ktalk?), so that a communication channel is available to the one at the console.