The key format is changing in
https://invent.kde.org/frameworks/kconfig/-/merge_requests/184; take
that into account here.
Currently this function copies code from KWindowConfig, which is not
ideal; a more robust solution would be to expose the config file key
value publicly using a function in KWindowConfig that Konsole can call.
That's KF6 material, though, so for now, let's fix this issue by simply
supporting the new key format as well as the old one.
Add a profile option to follow Unicode standard for the display width of
characters, where this width differs from glibc's wcwidth.
Currently the only character affected by this is soft hyphen (unicode 0x00ad).
Konsole generally follows wcwidth() function when determining the display
width of characters, since this is behaviour expected by libreadline, and
doing otherwise corrupts lines containing problematic characters. When such
characters are used more for display, then on the command line, following
the Unicode standard may be prefferable.
The default for this option is disabled - that is follow wcwidth().
CCBUG: 464823
Konsole's code base uses a MAX_LINE_WIDTH define, currently set to 1024,
to act as sizes for various buffers used with ICU text shaping
algorithms, but no range checks are ever performed on those, meaning
that a display area of more than 1023 character cells wide will overflow
said buffers.
This can happen if you have a very large display, a small font size, or,
egregiously, if you disconnect all displays when running under a Wayland
compositor, prompting qt.qpa.wayland to create a fake screen of
potentially huge size.
This commit takes the easy way out by clamping the TerminalDisplay size
to MAX_LINE_WIDTH-1, which is large enough for most users (1023), and
better than crashing due to buffer overflows anyway.
- Remove duplicate entries in cmake file
- Remove not needed EXPORT macros
- Move WindowSystemInfo.cpp to konsoleprivate instead of duplicating it
which is incorrect
I tried to start porting konsole on windows but there are too many
issues. These are fixes for some of the things I noticed
Qt6 added assert for qBound when min > max.
This can happen if you try to select text that's after whitespace
because then length will be before start causing negative max.
This fixes a memory leak and, frankly, speculative cases where
double-click selected text that shouldn't be copied, is copied.
- don't leak QMimeData in case it isn't eventually submitted to
the clipboard - don't even create it
- get rid of the separate flag for pending double-click copy text,
just check if the paste text is empty
- Consolidate the two QTimers started after a double click. QTimer
has some guarantees about order of starting and order of
triggering of timers, but it's more obvious to just do things
from one timer. Also slightly more efficient.
- Always cancel double-click paste if any other paste happens
before the timeout - add code to that effect in the most generic
copying code paths. I'm not quite sure if all possible cases
work correctly now. Many things can happen with all the
selection modes supported + all the possible user input events.
If a middle button click is pressed while waiting for a triple click,
the word selected by double click needs to be copied to the buffer before
pasting.
A bug introduced in 0752cf3d prevents copying selection to clipboard if
a key is pressed a short time after a double click. This is avoided by:
- Do not exit selection mode in the time interval between a double click
and a (potential) third click.
- Save the selection text on a double click, and copy the saved text,
rather than the current selection if no third click at the end of the
triple click interval.
BUG: 463268
Split horizontal/vertical/auto from next tab acts like the usual split view
but takes the first session of the next tab, instead of creating a new
session. This allows for merging two separate tabs into a single tab.
The function to update the cursor when it blinks off has to update the
display according to visual cursor positions. Before 22.12, the cursor's
visual position was always identical to its logical, but now it may differ
when its inside an RTL string.
When painting the cursor, its visual position is known, so save it for
using in updateCursor().
1. Surrounding text does not make sense for terminal, because
surrounding text is used by input method for text predication, usually
used together with deleteSurroundingText (commitString with negative
offset), which is impossible for terminal application because it
requires directly modify the buffer. Return value for surrounding
text may cause invalid expectation from input method, e.g. input
method may wrongly treat the command prompt as a part of text in the
text buffer.
2. Fallback inputMethodQuery to QWidget default implementation, this
allows ImHint to use QWidget::inputMethodHints().
3. Set default input method hints that makes sense for terminal.
This is bug #373232 again. The rendering rewrite in 76f879cd7 reenabled
antialasing in a too wide context, causing the bug to reappear.
After #373232, the situation was that QPainter::TextAntialiasing instead
of QPainter::Antialiasing would be enabled depending on the "Smooth
fonts" setting, and QPainter::Antialiasing would be enabled depending on
that same setting just for TerminalPainter::drawLineCharString(). Go
back to that situation.
BUG: 462914
