global shortcut resolution (the KGlobalAccel methods) work on
application level, X11 as far as I can tell does not have a method to
tell which application has grabbed a key (to fill KGlobalShortcutInfo).
other than that no configuration interface for global shortcuts (not by
KGlobalAccel itself, plasma and its applets have interface for that),
also the shortcuts interface did not and still does not handle global
shortcuts well so that is something to look into.
one of the problems solved with this change is the fact that multiple
plasma applets (e.g. multiple instances of the keyboard applet) could
not use the same shortcut, now it is possible. as for which applet gets
the shortcut action it is the one that has the grab first - that is how
key grabbing works in X11
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
because KTextEdit inherits QTextEdit it is rich text-capable and the
actions that KRichTextEdit and KRichTextWidget provide are not used
anywhere (the actions require explicit setup)
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>
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>
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>
KDateTime shall be used only for storing date and time while KLocale
shall be used to display such, not even going to test what KDateTime
does because it is basically a few methods on top of QDateTime now.
and because QDateTime knows not much about calendar systems while
KLocale supports several it makes sense for KDateTime to not be used for
displaying date and time thus the TODOs for KLocale are simply removed
note that KLocale still uses its own parser and formatter which means
that the change affects only KDateTime and its uses, not KLocale
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
simplifies startup notification for example, external applications that
pass the "nofork" argument may fail (not uncommon to be passed to
konsole)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
ksysguard library already has a plotting class (KSignalPlotter) which
should be moved to kdeui library, plasma library also has a plotting
class (SignalPlotter) very similar to the one from ksysguard library
(KGraphicsSignalPlotter)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
