the PID check was racy, bonus points for not writing data at all to the
lock and not reading it meaning less disk I/O
oh, yes - by using O_CLOEXEC the lock is stale-safe
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
the service check is racy, KLockFile is as not (assuming the combination of
O_EXCL and O_CREAT is not racy which is not KLockFile's responsibility)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
that means to get the translations linking to solid library or calling
KGlobal::locale()->insertCatalog("solid_qt") is required
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
browser shall be determinted by the preferred service for "text/html",
"application/xhtml+xml" or any other MIME type for it (that includes
scheme handlers)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
note the check if khotkeys is automatically started - it was a KDED module
not started because of XDG autostart desktop file
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
cleaning up the mess, everything but KNotificationConfigWidget is
implemented.
not only does it not require additional D-Bus service (knotify) to
function but also does not transmit pixmaps over D-Bus, the features
to execute command or log to file are dropped and will not be
implemented.
also about markup support in notifications - if the server does not
support markup then it is supposed to strip it, see the spec:
https://specifications.freedesktop.org/notification-spec/notification-spec-latest.html#backwards-compat
meaning nothing should be done by KNotification itself because it is not
a server, it is just a proxy.
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
optional feature that requires "-tray" command line argument and replaces
what the `ksystraycmd` program was doing. requires "X-KDE-SysTray" entry
in the desktop file as indicator that the application supports "-tray"
argument, unlike `ksystraycmd` does not spawn extra process and even
session management will work properly for it (the argument is manually
added to the restart command)
the feature is very much tide to KMainWindow (and derived classes) but the
overhead is next to none when the "-tray" argument is not specified (the
status notifier is not created in such case) however if created an
expensive tooltip update is done whenever a window changes (may have to
look into optimizing it but then again - most of the code does nothing
unless the "-tray" argument is specified)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
palette and style shall be applied by the platform plugin, the font is
independant of the full Katana session (look for
KGlobalSettings::generalFont() for example, font from config is used here
and there because the config and thus KGlobalSettings offer fine grained
font selection for different purposes)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
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>
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>
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>
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>
