the output goes to the TTY and there is no rich text handler there, note
that the plain format for the "email" tag also contained entities (even
before the KuitSemantics reimplementation)
because the plain format for the "email" tag
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
by using properties defined in the spec (see
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s06.html)
what KService::DBusUnique (or X-DBUS-ServiceName and X-DBUS-StartupType)
was used for can be implemented but the difference is now standard
properties can be filled (with values that are correct) and (ab)used for
the same purpose, bonus points?
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
just another way to do what ASN does, the KService::DBusWait mode was
not used too. with this change however all of the process setup code is
moved to a seperate class and the responsibility of KLauncher about ASN
is reduced (ASN now works better for process that fork but if application
claims ASN support and does not send ASN finish then the timeout will be
reached)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
fixes the "waitforwm" command line option
(KApplicationPrivate::parseCommandLine() was called before the X11 atom was
created and atom was invalid) and doubles as optimization
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
to be used for KLocale::toLocale() binding and possible more (QLocale
can now be constructed in .qml files and more importantly it will have
getters)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
see the following commit in kde-workspace repo:
f1f6ae7a3ec35e289df1f45cd47e71bd3c696fbe
on a side note the default for StartupNotify should probably be false as it
is unknown if the application actually supports startup notification is one
of the reasons why currently KLauncher does more than merely set an
environment variable and assume applications know what to do with it
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
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>
