feat: add Konsole recipe source and patches
This commit is contained in:
@@ -0,0 +1,52 @@
|
||||
|
||||
Items for the Konsole maintainer:
|
||||
=================================
|
||||
|
||||
A new maintainer may need super powers for some of these. If so, put in a
|
||||
request.
|
||||
https://go.kde.org/systickets
|
||||
|
||||
A. New releases
|
||||
1. Update src/main.cpp for version (2.7, 2.7.1, etc)
|
||||
a. Typically, Konsole is 2 versions behind KDE (KDE 4.7, Konsole 2.7)
|
||||
b. If no changes are made, don't increase version.
|
||||
2. Verify KDE bug site has all versions
|
||||
a. When a new x.y release is coming out, create the x.y and all x.y.z
|
||||
Example: 2.8, 2.8.1, 2.8.2, 2.8.3, 2.8.4, 2.8.5
|
||||
b. https://bugs.kde.org/editversions.cgi?product=konsole
|
||||
At the bottom there is an 'Add' link
|
||||
3. Once a x.y release comes out, in git master change version to x.y+1.999
|
||||
and add that to the Konsole BKO version.
|
||||
Example, 4.7 has been branched and git master is open again, change
|
||||
version to 4.7.999 in master.
|
||||
4. Usually the KDE release team handles the git tagging
|
||||
|
||||
B. Handbook
|
||||
1. For x.y release try to keep handbook up to date.
|
||||
2. Handbook is the index.docbook in konsole/doc/manual/
|
||||
|
||||
C. Sites
|
||||
1. konsole.kde.org is the only site the maintainer is responsible.
|
||||
a. It is currently in git (2012).
|
||||
https://projects.kde.org/projects/websites/konsole-kde-org
|
||||
b. If it becomes to much work or outdated, it might be forwarded to
|
||||
https://userbase.kde.org/Konsole
|
||||
|
||||
D. Mailing list
|
||||
1. https://mail.kde.org/mailman/admin/konsole-devel
|
||||
Password is given from previous maintainer (or someone who knows it).
|
||||
Robert Knight or Kurt Hindenburg
|
||||
2. As of 2013, all new subscriptions and first post require admin
|
||||
approval. This was done to cut down on spam on the list. These
|
||||
options can be changed on the link in #1
|
||||
|
||||
Links
|
||||
1. General Konsole bug page:
|
||||
https://bugs.kde.org/editproducts.cgi?action=edit&product=konsole
|
||||
2. An attempt to get more interest in Konsole
|
||||
https://userbase.kde.org/KonsoleDevelopment
|
||||
3. HTML version of Handbook
|
||||
https://docs.kde.org/?application=konsole
|
||||
4. KDE schedule https://community.kde.org/Schedules
|
||||
|
||||
|
||||
@@ -0,0 +1,133 @@
|
||||
Developer Documentation for Konsole
|
||||
|
||||
NOTE: this document is from 2007; a lot has changed. Please ask on the
|
||||
Konsole mailing list if you need any guidance.
|
||||
|
||||
Authors: Robert Knight < robertknight@gmail.com >
|
||||
Last Updated: 7th May 2007
|
||||
Summary: Introduction to Konsole developer documentation
|
||||
===============================================================
|
||||
|
||||
Contents:
|
||||
|
||||
1. Introduction
|
||||
2. Documentation format
|
||||
3. Documentation layout (aka. 'Where to find things')
|
||||
4. Contributing to Konsole
|
||||
4.1 Discussion and help
|
||||
4.2 Submitting code
|
||||
4.2.1 API documentation guidelines
|
||||
4.2.2 Code style guidelines
|
||||
|
||||
===============================================================
|
||||
|
||||
1. Introduction
|
||||
|
||||
This document explains the layout of the developer documentation folder,
|
||||
and basic guidelines for contributors.
|
||||
|
||||
2. Documentation format
|
||||
|
||||
To try and make it easier for developers to find the information they need
|
||||
about Konsole, the use of a standard document template which answers the following
|
||||
questions is encouraged:
|
||||
|
||||
- What is this document?
|
||||
- Who wrote it?
|
||||
- When was it last updated?
|
||||
- What is it about?
|
||||
- Where can I find information about <subject> within this document?
|
||||
|
||||
The current template can be found in design/developer-documentation-template
|
||||
|
||||
There is older documentation in the old-documents/ folder which does
|
||||
not follow this format. This is kept as a reference. Assistance
|
||||
in tidying up documentation from that directory by using the documentation
|
||||
template would be appreciated.
|
||||
|
||||
3. Documentation layout
|
||||
|
||||
DELETED design/ - Documentation about the design of Konsole, and templates
|
||||
for developer documentation.
|
||||
DELETED design/historic - Documentation which was prepared during the KDE 4.0x development
|
||||
cycle but which is no longer relevant.
|
||||
|
||||
DELETED research/ - Results of research into user's experiences with Konsole
|
||||
|
||||
DELETED user-interface/ - Documentation concerning design and analysis of the user interface.
|
||||
|
||||
DELETED old-documents/ - An assortment of documentation which was created during earlier
|
||||
releases of Konsole. There is useful information here, particularly
|
||||
about the type of terminal which Konsole emulates, but it is not
|
||||
organised.
|
||||
|
||||
4. Contributing to Konsole
|
||||
|
||||
Help with Konsole's development, whether it involves code, user interface suggestions or
|
||||
other resources is greatly appreciated.
|
||||
|
||||
4.1 Discussion and help
|
||||
|
||||
Discussion about Konsole development takes place primarily on the Konsole mailing list,
|
||||
at konsole-devel@kde.org. If you need help with Konsole development or wish to discuss
|
||||
implementation of a feature, fixes to bugs etc., then this is an appropriate place to
|
||||
do that.
|
||||
|
||||
4.2 Submitting code
|
||||
|
||||
Patches can be submitted for Konsole in a number of places:
|
||||
|
||||
- For bugfixes, we recommend that you attach the patch to the relevant bug report on bugs.kde.org
|
||||
- For new features, a patch can be attached to a relevant wishlist report on bugs.kde.org if
|
||||
there is one, and/or submitted to konsole-devel@kde.org
|
||||
|
||||
If your patch adds new methods or classes then please ensure that there is API documentation for
|
||||
them in the code. Looking at the header files for existing classes should give you an idea of
|
||||
what is asked for.
|
||||
|
||||
|
||||
4.2.1 API documentation guidelines
|
||||
|
||||
Good API documentation in the code is very helpful for other developers. Here are a few guidelines on
|
||||
writing API documentation for Konsole:
|
||||
|
||||
- All classes should have documentation which describes the basic function of the class.
|
||||
Usage examples are appreciated.
|
||||
- All public and protected methods should have API documentation which describes what
|
||||
the method does and what the returned value (if any) means.
|
||||
Parameter documentation is encouraged if the method has more than a couple of parameters
|
||||
or if the use of a parameter is not immediately clear from its name and type.
|
||||
- All public and protected enumerations and constants should have API documentation which
|
||||
describes what the various values mean.
|
||||
- The usage of brief standard comments next to private methods is encouraged to
|
||||
provide a quick explanation of what that method does.
|
||||
|
||||
4.2.2 Code style guidelines
|
||||
|
||||
The API style roughly follows that used in the Qt and KDE classes.
|
||||
|
||||
There are no strict guidelines on aspects of the code such as indentation, braces
|
||||
or spacing, although following the style of the existing code is a good idea.
|
||||
|
||||
Below is a list of the most important style considerations which have been developed
|
||||
following experience working on earlier Konsole code:
|
||||
|
||||
- Variables and methods should have CLEAR, verbose names. The use of abbreviations
|
||||
should be avoided except for very common cases.
|
||||
|
||||
- The use of named constants is preferred over literals for clarity, and also to prevent
|
||||
the need to edit each instance of a literal if the value needs to be changed.
|
||||
|
||||
- The use of macros ( #define ) should be avoided where possible. enums, inline methods
|
||||
templates, static constants etc. are strongly preferred.
|
||||
- Inside classes, private member fields have an underscore prefix ( eg. _myPrivateField )
|
||||
- Private slots in classes DO NOT have a "slot" prefix before their name which is often
|
||||
seen in other KDE applications.
|
||||
|
||||
Earlier Konsole code had a proliferation of two-letter variable names, which made it hard
|
||||
to read and understand in some places, and let directly to bugs in others. Descriptive naming
|
||||
and sensible use of comments are strongly encouraged in new code.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,42 @@
|
||||
# Add this to your .gitconfig after renaming/moving/etc
|
||||
#[commit]
|
||||
# template = ~/.commit-template
|
||||
#
|
||||
# Please enter the commit message for your changes. Lines starting
|
||||
# with '#' will be ignored, and an empty message aborts the commit.
|
||||
# You MUST wrap all lines at 72 characters.
|
||||
# https://community.kde.org/Policies/Commit_Policy
|
||||
# https://community.kde.org/Infrastructure/GitLab#Write_a_good_commit_message
|
||||
# For Git commit hook keywords see:
|
||||
# https://community.kde.org/Policies/Commit_Policy#Special_keywords_in_GIT_and_SVN_log_messages
|
||||
# ==[ Subject: One line ONLY short meaningful description for logs ]===|
|
||||
|
||||
# ==[ Blank: Follow the Subject with a blank line, do NOT remove ]=====|
|
||||
|
||||
# ==[ Details: Describe what changed and explain why it changed]=======|
|
||||
|
||||
|
||||
# ==[ Fields: Uncomment and edit where applicable ]====================|
|
||||
# --[ Close bug in bugs.kde.org as fixed ]-----------------------------|
|
||||
#BUG: <bug number>
|
||||
#FIXED-IN: <optional release version>
|
||||
# --[ Add to release changelog optionally close wish in bugs.kde.org ]-|
|
||||
#FEATURE: <optional bug number>
|
||||
#FIXED-IN: <optional release version>
|
||||
# --[ Copy commit message to a bug or wish in bugs.kde.org ]-----------|
|
||||
#CCBUG: <bug number>
|
||||
# --[ Copy commit message to an email address ]------------------------|
|
||||
#CCMAIL: <email>
|
||||
#
|
||||
# --[ Notify documentation team of user visible changes ]--------------|
|
||||
#GUI:
|
||||
#
|
||||
# --[ Notify team of something interesting ]-------------|
|
||||
#CHANGELOG:
|
||||
#
|
||||
# --[ Mark commit as silent for commit filter filtering. ]-------------|
|
||||
# [ Use sparingly and only for uninteresting and ]
|
||||
# [ uncontroversial commits. ]
|
||||
#GIT_SILENT
|
||||
#
|
||||
|
||||
+97
@@ -0,0 +1,97 @@
|
||||
#!/bin/bash
|
||||
# Add this to your konsole/.git/hooks/ folder to prevent push if message is not following commit-template
|
||||
# In your konsole folder type:
|
||||
# cp ./doc/developer/pre-push ./.git/hooks/pre-push && chmod +x ./.git/hooks/pre-push
|
||||
|
||||
# Get the current branch and apply it to a variable
|
||||
currentbranch=`git branch | grep \* | cut -d ' ' -f2`
|
||||
|
||||
# Gets the commits for the current branch and outputs to file
|
||||
git log $currentbranch --pretty=format:"%H" --not master > shafile.txt
|
||||
|
||||
if [ ! -f "./shafile.txt" ]
|
||||
then
|
||||
echo "It is not possible to write temporary files"
|
||||
echo "Check Read/Write permissions or remove this"
|
||||
echo "pre-push check"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
if [ ! -s "./shafile.txt" ]
|
||||
then
|
||||
# if size is 0 there is no commit
|
||||
rm shafile.txt >/dev/null 2>&1
|
||||
exit 0
|
||||
fi
|
||||
|
||||
echo '
|
||||
====================
|
||||
Commit Message Check
|
||||
====================
|
||||
'
|
||||
|
||||
#colors used here
|
||||
RED='\033[0;31m'
|
||||
GREEN='\033[0;32m'
|
||||
NC='\033[0m'
|
||||
|
||||
passedall=0
|
||||
# loops through the file an gets the messages
|
||||
for i in `cat ./shafile.txt`;
|
||||
do
|
||||
passed=0
|
||||
# gets the git commit message based on the sha
|
||||
git log --format=%B -n 1 "$i" > logfile.txt
|
||||
# load this message to an array
|
||||
mapfile -t gitmessage < ./logfile.txt
|
||||
|
||||
# commit title
|
||||
echo "- ${gitmessage[0]}"
|
||||
|
||||
# analise each line
|
||||
for (( nline=0; nline<${#gitmessage[@]}+1; nline++ ));
|
||||
do
|
||||
line=${gitmessage[$nline]}
|
||||
if [ ${#line} -gt 72 ]
|
||||
then
|
||||
echo -e " ${RED}*${NC} You MUST wrap all lines at 72 characters."
|
||||
passed=1
|
||||
fi
|
||||
|
||||
if [[ $nline -eq 1 && ${#line} -gt 0 ]]
|
||||
then
|
||||
echo -e " ${RED}*${NC} Follow the Subject with a blank line."
|
||||
passed=1
|
||||
fi
|
||||
|
||||
messagecheck=`echo $line | grep -w "BUG\|FEATURE\|FIXED-IN\|CCBUG\|CCMAIL\|GUI\|CHANGELOG"`
|
||||
if [ -n "$messagecheck" ]
|
||||
then
|
||||
messagecheck=`echo $line | grep ': '`
|
||||
if [ -z "$messagecheck" ]
|
||||
then
|
||||
echo -e " ${RED}*${NC} Your commit message has a formatting error."
|
||||
echo " Type ' ' after field specification"
|
||||
echo " -> $line"
|
||||
passed=1
|
||||
fi
|
||||
fi
|
||||
done
|
||||
|
||||
# Check if all passed
|
||||
if [ $passed -gt 0 ]
|
||||
then
|
||||
echo -e " Commit message ${RED}FAILED${NC}"
|
||||
passedall=1
|
||||
else
|
||||
echo -e " Commit message ${GREEN}PASSED${NC}"
|
||||
fi
|
||||
echo ""
|
||||
done
|
||||
# remove temporary files
|
||||
rm shafile.txt >/dev/null 2>&1
|
||||
rm logfile.txt >/dev/null 2>&1
|
||||
# Test mode remove the next '#' to test it
|
||||
#exit 1
|
||||
# If all passed in the check it will exit 0
|
||||
exit $passedall
|
||||
@@ -0,0 +1,5 @@
|
||||
########### install files ###############
|
||||
|
||||
KDOCTOOLS_CREATE_HANDBOOK(index.docbook
|
||||
INSTALL_DESTINATION ${KDE_INSTALL_DOCBUNDLEDIR}/en
|
||||
SUBDIR konsole)
|
||||
@@ -0,0 +1,6 @@
|
||||
Use CheckXML to verify the file is valid XML
|
||||
Use meinproc5 to create an HTML version for local viewing.
|
||||
|
||||
Remember to update the date and releaseinfo when you want the the translators
|
||||
to see the new version.
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 7.1 KiB |
File diff suppressed because it is too large
Load Diff
@@ -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