not used in plain context, same as "p" in rich context. also now Katie will
detect the paragraphs as rich text
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
I intend to rewrite kconfig_compiler at some point (possible to use JSON
format) and the tests will be done anew
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
fun fact: there is CLDR data for ~1000 languages and only ~50 use different
number system (not "latn")
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
text with "<" in it is considered as rich text by Qt::mightBeRichText()
as special case. also entities are not markup and shall not be handled by
KuitSemantics (there is a class for that - KCharsets). entity is used
only in one place (kde-workspace/kate/part/view/kateviewhelpers.cpp) and it
does not even need special handling by KuitSemantics. so, instead of
slowing the whole markup parsing with redundant and unused feature I've
decided to not support it and even improve Katie's Qt::mightBeRichText()
function
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
is interesting how much simpler it can be by assuming that the tags are
strict and by using Qt::mightBeRichText() for the rich text detection.
while mostly compatible (entities are not converted, some tags were not
used and some even did not do anything) it is subject to optimization by
using QStringMatcher or other tricks (like using a separate tag for the
numbers precision)
overall - no regular expression matching, no XML parser is used and does
what the old implementation was doing but with less code. also passes
most tests (the exception is KLocalizedString test case that expect
entities to be replaced)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
there were 3 copies of it, only one with minor changes. by moving it
here any changes that have to be done to it will not have to be done to
the copies aswell.
TODO: move its private members to KTimerDialogPrivate
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
the device was opened for reading only but for the version to be written
it has to be opened for writing too
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
so that the color schemes can be opened and edited via text editor by
default (the files are essentially INI files)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
generally KRun does not start processes as detached process and as soon as
the process is launched and KRun::finished() is emitted KRun is deleted,
that however means that when the program that used KRun to launch
something exits the launched program will be terminated. while in most
cases that is not an issue (for services that have valid path for example)
for `kde-open` it is because its lifetime is short and the command to
execute is obtained via KProtocolInfo::exec() (QString, not KService)
so, to launch the scheme handlers as detached process (because the
programs that handle such may not fork) KRun has to use KToolInvocation
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
with the rewrite (see f452e2e50b),
KDateTime is just glue-code for compatibility now. the exception is
KDateTime::isNightTime() (written by me) which is used only in one place
(kde-workspace/plasma/dataengines/weather/ions/wetter.com/ion_wettercom.cpp)
and can be moved there
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
because the message overlay is used for both (error) messages and to show
configuration button (with optional message) and the overlay may have to
be recreated to override the one previously setup by
Plasma::Applet::showMessage() (e.g. when an applet is created, message is
shown and then a configuration overlay but with the internal "requries
configuration" state not changing)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
this makes KIcon serializable by name (e.g. by KDBusMenuExporter) in
most cases, that however means lookup on the other end (if the icon pixmap
is not serialized it is essentially the same as calling QIcon::fromTheme()
on the other end of the serialization)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
KRatingPainter and KRatingWidget are currently not used but holding a
reference to a pixmap that can already be (and is) obtained from the icon
(constructing QIcon from pixmap is a thing) is just redundant
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
this is mostly for status notifier dialogs, if the dialogs are not raised
and activated they will block (because QDialog::exec() is called) and
manual activation has to be done (via alt+tab)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
does nothing but slow down the image serialization on little endian really,
the image data is not ment to be saved and passed around to other host
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
Katie has the option to set printer properties and options anyway, as
for why the bits are non-operational - it is because of the version
check which is lower than the current Katie version
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
checking for directory existing via QFile::exists() is bogus, also Katana
does not install files in such directory
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
by checking if the unmodified (by makeLibName()) name is absolute first and
by not checking for relative library (if the name is not absolute path
QFileInfo::path() would return "." resulting in a relative lookup for
the library by KStandardDirs::findResource() in "lib" resource) the most
common cases are only looked for by KPluginLoader (either absolute path,
relative module or library but not relative to the current directory)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
unless KAboutLicense is merged into KAboutData that cannot happen because
KAboutData has getters that use the enums
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
