feat: add Konsole recipe source and patches
This commit is contained in:
@@ -0,0 +1,114 @@
|
||||
[README.fonts]
|
||||
|
||||
Fonts need to suit the needs of X11, QT and konsole.
|
||||
|
||||
|
||||
* the font has to be fixed width.
|
||||
|
||||
This requirement originate both from X11 and
|
||||
the way QT and konsole uses it together with
|
||||
the very idea of what a terminal emulation is
|
||||
about.
|
||||
|
||||
Basically, a terminal emulation is to display
|
||||
a character cell oriented screen, meaning that
|
||||
all characters in the same column line up
|
||||
properly under each other.
|
||||
|
||||
Though one could make this with a variable
|
||||
width font (which are preferably used in text
|
||||
processing) the outcome would look very poor,
|
||||
since the glyphs would have to be placed into
|
||||
a cell fitting the widest character in the
|
||||
font, which is typically more than two times
|
||||
wider than the narrowest glyph. Imagine a text
|
||||
with l o t s o f s p a c e s
|
||||
inserted between each character to get the idea.
|
||||
|
||||
Further, doing this with a variable width font
|
||||
means to do some operations that slow down the
|
||||
whole display refreshing dramatically. X11/QT
|
||||
performs very poor when one draws characters
|
||||
individually while additionally clearing
|
||||
background regions instead of drawing a complete
|
||||
string (as konsole does). If one draws a string
|
||||
with a variable width font, it is of course
|
||||
typeset by X11 variable width, not longer
|
||||
conforming to the character cell model of a
|
||||
terminal emulation.
|
||||
|
||||
So from both perspectives, variable width fonts
|
||||
are unsuited for terminal emulation purposes.
|
||||
|
||||
|
||||
* the font has to contain some graphical characters
|
||||
|
||||
Many full screen applications make use of these
|
||||
characters to draw boxes, scroll bars and likely
|
||||
pseudo graphical entities.
|
||||
|
||||
Using fonts without this capabilities means to
|
||||
break the visual appearance of these products.
|
||||
|
||||
As a minimum the following glyphs have to be
|
||||
included within a font to become usable:
|
||||
|
||||
- 0x0b U+2518 : BOX DRAWINGS LIGHT UP AND LEFT
|
||||
- 0x0c U+2510 : BOX DRAWINGS LIGHT DOWN AND LEFT
|
||||
- 0x0d U+250c : BOX DRAWINGS LIGHT DOWN AND RIGHT
|
||||
- 0x0e U+2514 : BOX DRAWINGS LIGHT UP AND RIGHT
|
||||
- 0x0f U+253c : BOX DRAWINGS LIGHT VERTICAL AND HORIZONTAL
|
||||
- 0x10 U+23ba : HORIZONTAL SCAN LINE-1
|
||||
- 0x11 U+23bb : HORIZONTAL SCAN LINE-3
|
||||
- 0x12 U+2500 : BOX DRAWINGS LIGHT HORIZONTAL (scan line 5)
|
||||
- 0x13 U+23bc : HORIZONTAL SCAN LINE-7
|
||||
- 0x14 U+23bd : HORIZONTAL SCAN LINE-9
|
||||
- 0x15 U+251c : BOX DRAWINGS LIGHT VERTICAL AND RIGHT
|
||||
- 0x16 U+2524 : BOX DRAWINGS LIGHT VERTICAL AND LEFT
|
||||
- 0x17 U+2534 : BOX DRAWINGS LIGHT UP AND HORIZONTAL
|
||||
- 0x18 U+252c : BOX DRAWINGS LIGHT DOWN AND HORIZONTAL
|
||||
- 0x19 U+2502 : BOX DRAWINGS LIGHT VERTICAL
|
||||
|
||||
- 0x01 U+25c6 : BLACK DIAMOND
|
||||
- 0x02 U+2592 : MEDIUM SHADE
|
||||
- 0x1F U+00b7 : MIDDLE DOT
|
||||
|
||||
Also, the VT100 knows about the following glyphs,
|
||||
though omitting them is unlikely to break anything.
|
||||
|
||||
- 0x07 U+00b0 : DEGREE SIGN
|
||||
- 0x08 U+00b1 : PLUS-MINUS SIGN
|
||||
- 0x1a U+2264 : LESS THAN OR EQUAL TO
|
||||
- 0x1b U+2265 : GREATER THAN OR EQUAL TO
|
||||
- 0x1c U+03c0 : GREEK SMALL LETTER PI
|
||||
- 0x1d U+2260 : NOT EQUAL TO
|
||||
- 0x1e U+00a3 : POUND SIGN
|
||||
|
||||
Additionally, digraphs are provided for some
|
||||
of the control characters by VT100, too.
|
||||
|
||||
- 0x03 U+2409 : DIGRAPH HT
|
||||
- 0x04 U+240c : DIGRAPH FF
|
||||
- 0x05 U+240d : DIGRAPH CR
|
||||
- 0x06 U+240a : DIGRAPH LF
|
||||
- 0x09 U+240d : DIGRAPH NL
|
||||
- 0x0a U+240b : DIGRAPH VT
|
||||
|
||||
The mapping of non-iso10646 fonts is extended by konsole
|
||||
with the regular xterm fixed font placement of these
|
||||
glyphs to 0x00-0x1f.
|
||||
|
||||
|
||||
* Iso10646 fonts needs to have a fall back character
|
||||
to be properly assigned.
|
||||
|
||||
Use the "DEFAULT_CHAR" property with bdf fonts
|
||||
to do so. Other font representations provide
|
||||
likely means. The unicode assignment is U+fffd.
|
||||
|
||||
If such a character isn't defined, X11 might
|
||||
choose to void the character completely, causing
|
||||
inconsistent appearance when refreshing the screen.
|
||||
|
||||
One may choose the space glyph to hide the flaw
|
||||
or a box like one to exhibit it.
|
||||
@@ -0,0 +1,44 @@
|
||||
[README.keyboard]
|
||||
|
||||
The *.keytab files (located in /usr/share/applications/konsole and
|
||||
~/.local/share/applications/konsole) allow you to configure the keyboard
|
||||
to suit your specific environment/requirements.
|
||||
|
||||
Beside that you can use them to make the keyboard emit virtually any
|
||||
escape sequence you want, here are some notes about the more typical
|
||||
problems related to keyboards, that can be coped with this way:
|
||||
|
||||
- BS Hack
|
||||
|
||||
While one would expect, that the Backspace key send ASCII Backspace,
|
||||
this is not the case in many Linux installations.
|
||||
|
||||
The idea behind this hack is to preserve the CTRL-H.
|
||||
|
||||
So the mapping is:
|
||||
|
||||
CTRL-H -> 0x08
|
||||
Backspace -> 0x7f
|
||||
Delete -> \E[3~
|
||||
|
||||
- Home/End Keys
|
||||
|
||||
Home -> \E[1~
|
||||
End -> \E[4~
|
||||
|
||||
or
|
||||
|
||||
Home -> \E[H
|
||||
End -> \E[F
|
||||
|
||||
Quite a lot of those key sequences are floating around.
|
||||
|
||||
Consult your terminfo or termcap database for the expected values.
|
||||
Note that your system is not unlikely to have other keyboard databases
|
||||
which have to be in sync, too (e.g. /etc/inputrc for readline(3)).
|
||||
|
||||
If you want to adjust things to your needs you can copy one of the *.keytab
|
||||
files and edit it. The changes will take effect after restarting konsole.
|
||||
|
||||
In case your new keytab is likely to suit common needs, please contribute
|
||||
to konsole by sending us the file.
|
||||
@@ -0,0 +1,88 @@
|
||||
Konsole and the Linux console
|
||||
|
||||
|
||||
From a technical point of view, the Linux console differs
|
||||
so substantially from any other terminal, that it impossible
|
||||
to fully emulate it. This is because the Linux console lives
|
||||
in kernel space and interfaces by kernel means, which cannot
|
||||
be simulated by any user space application.
|
||||
|
||||
Contrary to this fact, konsole can be configured to appear
|
||||
and function console like to a degree that makes it virtually
|
||||
indistinguishable from the original. To do so, switch off the
|
||||
menubar, scrollbar and frame, select the Linux colors and font
|
||||
and set the full screen mode.
|
||||
|
||||
If you're running the console with the same resolution as
|
||||
your X display (which you can, thanks to the frame buffer
|
||||
console), you should get a pixel identical display then,
|
||||
despite the fact that you're still running an X terminal.
|
||||
|
||||
|
||||
* What make the Linux console so unique?
|
||||
|
||||
The central differences between the Linux console and xterm
|
||||
like emulations are:
|
||||
|
||||
1) The Linux console uses some special devices (vcs,vcsa)
|
||||
and ioctls for some purposes, for which no correspondent
|
||||
escape codes exist.
|
||||
2) The Linux console uses gpm for the mouse.
|
||||
3) The Linux console does not have an application screen.
|
||||
Xterm like application switch from a primary screen to
|
||||
the application screen when running in full screen mode,
|
||||
keeping the shell session apart from the application.
|
||||
Application like MC emulation the application screen on
|
||||
the Linux console using the devices mentioned in 1).
|
||||
4) The Linux console may use a character map different from
|
||||
the one used in X11.
|
||||
5) The TERM environment variable is "linux"
|
||||
6) A few key codes (F1-F5) differ.
|
||||
7) The Linux console occupies the whole display.
|
||||
|
||||
Clearly, 1) and 2) make the Linux console so distinct that
|
||||
an explicit Linux console simulation cannot exist.
|
||||
|
||||
|
||||
* Running Konsole in true Linux console mode:
|
||||
|
||||
To some degree, one can run application with Linux console
|
||||
emulation, too.
|
||||
|
||||
- export TERM=linux to trigger ncurses aware applications
|
||||
to expect a linux console.
|
||||
- set the appropriate codec (this is cp437 on my installation)
|
||||
to get graphical and international characters properly.
|
||||
[TODO: to control codec via menu settings is work in progress, meaning not available yet.]
|
||||
- set the Linux keyboard to get the F1-F5 function keys right.
|
||||
|
||||
In general it is NOT advisable to ever modify the above
|
||||
indicated settings unless you know what you're doing.
|
||||
|
||||
Note that applications then may not react properly on changing
|
||||
the window size anymore. Often they ignore it completely or
|
||||
behave strange in other ways. I even saw one application dying
|
||||
from the shock of noticing that the linux console has simply
|
||||
changed it's size (Debian's dselect). Since the Linux console
|
||||
can be resized, this behavior is to be considered a bug in
|
||||
these applications, i cannot help it.
|
||||
|
||||
Mouse-aware application will most probably not recognize
|
||||
mouse events (especially mc) since they might try to get
|
||||
these events from gpm instead.
|
||||
|
||||
MC will not be able to access the special console devices
|
||||
then and cannot simulate a secondary screen, treating the
|
||||
emulation as "dummy" with respect to it (^O).
|
||||
|
||||
Some application will also assume that the default background
|
||||
is black, thereby producing random black background ranges.
|
||||
|
||||
The linux console can some funny quirks with special graphic
|
||||
characters and i will not teach Konsole all of them. In rare
|
||||
cases, they might display differently. Affected to my knowledge
|
||||
are especially non-VT100 extensions taken from the AT&T 4410v1,
|
||||
these are arrow symbols, a full block and a checker board. Most
|
||||
other tricks that the linux console is able to do with character
|
||||
sets are eventually not even used in a single instance, so you
|
||||
will hardly be disturbed by it.
|
||||
@@ -0,0 +1,98 @@
|
||||
[README.moreColors]
|
||||
|
||||
The konsole adopted some ESC codes allowing to use extended
|
||||
color spaces.
|
||||
|
||||
There is a predefined 256 color space compatible with his
|
||||
xterm sister, and, even beyond that, a 3-byte RGB color space.
|
||||
|
||||
The ESC codes are as follows:
|
||||
|
||||
ESC[ ... 38;2;<r>;<g>;<b> ... m Select RGB foreground color
|
||||
ESC[ ... 48;2;<r>;<g>;<b> ... m Select RGB background color
|
||||
|
||||
ESC[ ... 38;5;<i> ... m Select indexed foreground color
|
||||
ESC[ ... 48;5;<i> ... m Select indexed background color
|
||||
|
||||
<r>,<g> and <b> are each values in the range of 0..255 and
|
||||
represent the brightness as usual for the respective color.
|
||||
|
||||
<i> likely is a value in 0..256, but represents an indexed
|
||||
color assignment composed as follows:
|
||||
|
||||
0 .. 15 - System color, these are taken from the schema.
|
||||
16 .. 231 - Forms a 6x6x6 RGB color cube.
|
||||
232 .. 255 - A gray scale ramp without black and white.
|
||||
|
||||
Try the tests/color-spaces.pl to visualize the assignment.
|
||||
|
||||
|
||||
----------------------------------------------------------------
|
||||
|
||||
A note on conformance
|
||||
|
||||
These ESC codes break the "associativity" of SGR, but after some
|
||||
research the result is, that the standard itself is broken here.
|
||||
|
||||
The perhaps best codes due to ECMA-48 would probably be e.g.
|
||||
38:2:<r>:<g>:<b>, i.e. consistently a colon instead of a semicolon.
|
||||
But apparently, this is defined different in ISO-8613 (which is
|
||||
included at this place in ECMA-48), actually breaking ECMA-48.
|
||||
|
||||
We cannot help this and implemented the codes as above, which
|
||||
is a balanced decision.
|
||||
|
||||
For 256 color mode, this is compatible with xterm and perhaps
|
||||
with other xterm compatible terminal emulations.
|
||||
|
||||
|
||||
| ------- Additional Comments From awendt putergeek com 2006-06-07 07:40 -------
|
||||
| > So a parameter substring is 0-9 and the colon. The semicolon separates
|
||||
| > sub-parameters. Thus 48:5:<Color> would be one sub-parameter, and
|
||||
| > 48;5;<Color> many independent, each having an independent meaning in case
|
||||
| > of a selective parameter.
|
||||
|
|
||||
|
|
||||
| I think you may be onto something here with the colons... I was able to find
|
||||
| ITU T.416 (which is the same as ISO 8613-6) and it says:
|
||||
|
|
||||
| --- snip ---
|
||||
|
|
||||
| The parameter values 38 and 48 are followed by a parameter substring used to
|
||||
| select either the character foreground ?colour value? or the character
|
||||
| background ?colour value?.
|
||||
|
|
||||
| A parameter substring for values 38 or 48 may be divided by one or more
|
||||
| separators (03/10) into parameter elements, denoted as Pe. The format of such
|
||||
| a parameter sub-string is indicated as:
|
||||
|
|
||||
| Pe : P ...
|
||||
|
|
||||
| Each parameter element consists of zero, one or more bit combinations from
|
||||
| 03/00 to 03/09, representing the digits 0 to 9. An empty parameter element
|
||||
| represents a default value for this parameter element. Empty parameter
|
||||
| elements at the end of the parameter substring need not be included.
|
||||
|
|
||||
| The first parameter element indicates a choice between:
|
||||
|
|
||||
| 0 implementation defined (only applicable for the character
|
||||
| foreground colour)
|
||||
| 1 transparent;
|
||||
| 2 direct colour in RGB space;
|
||||
| 3 direct colour in CMY space;
|
||||
| 4 direct colour in CMYK space;
|
||||
| 5 indexed colour.
|
||||
|
|
||||
| If the first parameter has the value 0 or 1, there are no additional parameter
|
||||
| elements.
|
||||
|
|
||||
| If the first parameter element has the value 5, then there is a second
|
||||
| parameter element specifying the index into the colour table given by the
|
||||
| attribute ?content colour table? applying to the object with which the
|
||||
| content is associated.
|
||||
|
|
||||
| --- snip ---
|
||||
|
|
||||
| The separator character 03/10 they use is a colon, not a semicolon... I wonder
|
||||
| if the xterm implementation was based on an improper reading of the standard?
|
||||
|
|
||||
Reference in New Issue
Block a user