Konsole wasn't really keeping track of changes to line rendition
attributes, and was just always marking for update the top line of
double-height lines. This didn't account for double-width lines, changes
back to single-width single-height, and did not provide proper support for
separate rendering of the bottom of double-height lines.
The effect can be seen on vttest "Test of known bugs" (9) -> "Erase
right half of double-width lines" (8), where a line is changed from
single-width to double-width and back. The line wasn't re-rendered on
each change, as it should.
Can also be tested with:
echo -e "\e[2J\e[1;1HTEST\n"; sleep 1; echo -e "\e[1;1H\e#6\e[2;1H"
Double height lines are actually two lines, the first with the top part
of the characters, the second with the bottom part. Reflowing could lead
to situations where we render a top part, a double height line with its
top and bottom parts, and a bottom part, which looks weird.
There is a difference with xterm behavior: when the screen width is an
odd number of columns, xterm allows selecting up to columns/2+1, we just
allow selecting up to columns/2.
While DECDHL/DECDWL lines are not wrapped at the correct column, now at
least reflowing doesn't clear line rendition attributes, so resizing
Konsole and going back to the original size always recovers the original
content, including double-height/double-width status of each line.
Reflowing double-height lines doesn't make much sense, since a
double-height line actually consists of a top (T) and a bottom (B)
line. Shrinking them could lead to TTBB lines, which look weird. At
least now going back to the original size brings back the original
content in all its glory.
While DECHDL sequences should be used in pairs on adjacent lines, the
first line drawing the top half, and the second line drawing the bottom
half, apparently real VTxxx (or at least the VT220) terminals did draw
only the top or bottom of characters when confronted with an isolated
DECDHL line (https://retrocomputing.stackexchange.com/questions/18023/).
xterm has that same behavior. So behave likewise.
EL (Erase Line) should not reset the line rendition attribute to
single-width. ED (Erase Display) should only reset it for completely
cleared lines. ECH (Erase CHaracters) should obviously not reset it.
DECSED and DECSEL (Selective Erase, not supported by Konsole) should not
reset it.
This fixes a vttest test where a line is set to double-height-top and
then EL before writing its text and the double-height-bottom line below.
Can also be tested with:
echo -e "\e[2J\e[4;1HNormal\n\e#6DOUBLE\n\e#6DOUBLE\nNormal" &&
sleep 2; echo -e "\e[5;3H\e[1J\e[8;1H"
Some control functions special case the last column. When a line has
been set to double-width via DECDWL or DECDHL (double-height and
double-width), the correcr last column for that line should be used.
Control functions which special case the last column include TAB, CUF,
ICH and DECRC.
Can be tested with:
perl -E '$r=join "", map{$_%10}1..80; say "\e<\e[?40h\e[?3l\e[?7l$r";
$s="L"."\tx"x4 ."\t\tR"; say "\e#3$s\n\e#4$s"'
The above tests that tabs don't travel beyond the last column in
double-width lines. The last column (below columns 79 and 80 of
the previous line) should have an "R".
perl -E '$r=join "", map{$_%10}1..80; say "\e<\e[?40h\e[?3l\e[?7h$r";
$s="L"."X"x36 ."\e[6C"."R"; say "\e#3$s\n\e#4$s"'
The above tests that CUF (Cursor Forward) doesn't travel beyond the last
column in double-width lines. The last column (below columns 79 and 80
of the previous line) should have an "R".
perl -E '$r=join "", map{$_%10}1..80; say "\e<\e[?40h\e[?3l\e[?7h$r";
$s="L"."X"x22 ."R"."x"x8 ."r"."\e[17D\e[16@";
say "\e#3$s\n\e#4$s"'
The above tests that ICH (Insert CHaracters; VT200+) doesn't write past
the last column, visible on repaints (switch to another window and
back).
perl -E '$r=join "", map{$_%10}1..80; say "\e<\e[?40h\e[?3l\e[?7h$r";
$s="L"."X"x38 ."r\e7\e[H\e8R"; say "\e#3$s\n\e#4$s"'
The above tests that DECRC (Restore Cursor) doesn't restore the cursor
to a position beyond the last column on double-width lines. The last
column should have an "R", "r" should not be visible.
perl -E '$r=join "", map{$_%10}1..80; say "\e<\e[?40h\e[?3l\e[?7l$r";
$s="L"."X"x38 ."R"; print "\e#6$s"'; sleep 5; echo
The above tests that the cursor stays at the rightmost column. The
cursor should stay over the "R" for 5 seconds.
Since double-width/double-height lines have room for just half the
characters, take that into account.
Can be tested with:
perl -E '$r=join "", map{$_%10}1..80; say "\e<\e[?40h\e[?3l\e[?7h$r";
$s="L"."X"x38 ."RL"; say "\e#6$s"'
The above tests that appending characters to double-width lines in
DECAWM (Auto Wrap Mode) wraps at the correct last column. There should
appear a second line (single-width) with a single "L".
perl -E '$r=join "", map{$_%10}1..80; say "\e<\e[?40h\e[?3l\e[?7l$r";
$s="L"."X"x42 ." TEST FAILED OUTOFBOUNDS R"; say "\e#6$s"'
The above tests that appending characters to double-width lines in
non-DECAWM (Auto Wrap Mode) doesn't write past the last column (visible
on repaints - switch to another window and back). The last column (below
columns 79 and 80 of prev line) should have an "R".
When there were several runs of double width/double height runs with
differing color/rendition/line draw/..., the second and subsequent runs
were positioned wrong. Fix the calculation of the starting x position to
account for double width, and fix a bug were the y position was
incremented for every run instead of for every line.
Can be tested with:
perl -E '$s="\e[0mTEST\e[32mTEST\e[0m"; say "\e#3$s\n\e#4$s"'
KPageDialog already creates the accepted()/rejected() connections, since
the code here created another connection, the accept() slot was being
called twice for each OK button click, with e.g. the profile name empty,
clicking Ok:
- the first time isProfileNameValid() would return false, and the saving
would abort, as it should
- the second time around, isProfileNameValid() would return true since
the name has been reverted to the original value in the Name line edit
The same goes for the reject() slot.
Also use a lambda instead of apply(), it's a very small method and this
was the code is more readable, since we don't need to jump back and forth.
- If the QObject has a parent, the parent will take care of deleting it
- Use std::unique_ptr to manage pointer member variable
- Use '= default' with empty destructors
- Fix initialization of QTimer in constructor initialization list
Always pass a parent to a QObject constructor; this is always a good
idea, as it enforces the parent/child relationship, and it also means
the parent QObject will take care of deleting its children, less manual
'delete' calls.
_terminalPainter already has a TerminalDisplay parent object.
Use a std::unique_ptr to manage _printManager (it's not a QObject).
A KMessageWidget is nicer than a modal dialog, and now we also
automatically switch to the General page when the user tries to save
the settings while there is an issue with the profile name.
Now when creating a new profile, the title will be "Create new profile",
this is less confusing when the user tries to edit e.g. the Fallback profile,
which in effect will create a new profile as the Fallback one is immutable.
The terminalColor is a QWidget, created with the terminal display
as parent. if we are in the destructor that means that the
TerminalDisplay will delete this object when it's needed,
do not call delete directly.
Those Classes are not QObject, so most of it's pointers could be changed
to smart pointers with no problems.
Problem found when using QList<std::unique_ptr>: it wasn't possible to
use it. I'm using std containers instead.
This should prevent opening two instance of the EditProfileDialog in the
same process, i.e. if "run all konsole windows in a single process" option is:
- Enabled, then opening the dialog will block user interaction with all
other konsole windows (including tabs).
- Disabled, then open the dialog will block user interactin with all
other tabs in the same window
This simplifies the code since it checked if such a dialog was open
somewhere else to prevent crashes.
exec() creates a nested eventloop, which could lead to some nasty
crashes ...etc.
ProfileSettings::editSelected(): since the dialog is modal, the user
can't interact with the konsole window at all, so no chance of opening
another instance of the EditProfileDialog.
- If there is no selection only enable the "New" button, this fixes a
crash if you select a profile, then Ctrl+Click to unselect it, the set
as default button would still be enabled and clicking it caused a crash
- If a profile is selected, clone its properties, otherwise the fallback
profile properties will be used, this more expected
This is a first step in simplifying the code; since the Fallback profile
doesn't have a file on disk, it's basically a corner-case that we have to
babysit in various places in the code.
Now when the user tries to "Edit current profile", if it's the Fallback
profile, a new profile is created, with a unique name "Profile 1",
"Profile 2" ...etc. This is similar to using the "New" button in the
ProfileSettings dialog.
- Since the favourite profile feature was removed in commit 28ba920c82,
there is no need to sort profiles by menu index, this simlifies the code
some more.
- Remove Profile::menuIndexAsInt() method, now it's not used anywhere
- This also fixes an issue with sorting the the Default/fallback profile,
since commit ce31d0e235 it would be always sorted at the top of the
list (to signify that it's a special, read-only profile...etc), sorting
by menu index breaks that behaviour:
- create a new profile by editing the Defualt/fallback profile, and give
the new profile a name (Defualt is reserved of course)
- open the profile manager dialog, you'll find the Default/fallback
profile not at the top of the list, until you restart Konsole
This issue was reported by Kurt in
https://invent.kde.org/utilities/konsole/-/merge_requests/351#note_197432
Let the Default/fallback profile be shown in the Profile Manager dialog,
and disable the Edit and Delete buttons for it, it can be "cloned" by
using the New button.
BUG: 433210
FIXED-IN: 21.04
