Use the new std::random APIs in c++11 for generating random numbers,
which is much safer and doesn't abuse qsrand().
This also means we don't need to copy in the QUuid::createUuid() code
anymore, which generated a warning in ubsan.
REVIEW: 129342
Adds faint intensity, strikeout, conceal and overline support.
echo -e 'D\e[2mD\e[9mD\e[53mD\e[8mD'
Thanks to Antonio Russo antonio e russo gmail com for patch
REVIEW: 128405
BUG: 362171
(cherry picked from commit 84b43dfb21)
Adds faint intensity, strikeout, conceal and overline support.
echo -e 'D\e[2mD\e[9mD\e[53mD\e[8mD'
Thanks to Antonio Russo antonio e russo gmail com for patch
REVIEW: 128405
BUG: 362171
Previously when using an image as the background, the opacity was
ignored. This patch corrects that.
Many thanks for patch to Wolfgang Brehm wolfgang brehm gmail com
BUG: 312843
FIXED-IN: 2.13
(cherry picked from commit 09ca63dbb6)
Previously when using an image as the background, the opacity was
ignored. This patch corrects that.
Many thanks for patch to Wolfgang Brehm wolfgang brehm gmail com
BUG: 312843
FIXED-IN: 2.13
TerminalDisplayAccessible is disabled for Qt5 currently since I don't
have any experience with accessible stuff and it is more complicated
than just changing a few includes
REVIEW: 111937
To build for KF5 pass the option -DQT5_BUILD=ON to CMake
TerminalDisplayAccessible is disabled for Qt5 currently since I don't
have any experience with accessible stuff and it is more complicated
than just changing a few includes
REVIEW: 111937
Since the early KDE 4.x, konsole has allowed each color entry to have
a "Bold=true|false" entry to specify whether the color should be drawn
in bold or not (there was never an UI).
The per-profile 'Draw intense colors in bold font' should be enough.
See bko 168300 for more info
Note: this special colorscheme has never been exposed and put into use,
so the new files are not involved in the building process.
Maybe that special colorscheme should just be removed, if no one now
really understands its design purpose.
It is a little surprising this inconsistency of reading "Transparent"
and writing "Transparency" has been there for a few years. That fact
implies that entry might by totally useless in current code.
Need furthur investigation.
class KDE3ColorSchemeReader is also moved since it is supposed to an
compatibility helpr of which class ColorScheme does not need to know,
and eventualy it should be removed
This reverts commit 05f8cc339f.
The issue is that some of the color schemes are in the KDE3 format
and some in KDE4. This close to 4.8, I'll revert and fix later.
BUG: 286205
Kurt Hindenburg
Martin T. H. Sandsmark
Alex Richardson
Jekyll Wu