and since this is done by KApplication it is bound to it, finally shortcuts
are saved and restored tho
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
there may be a case of not having any items (e.g. only global shortcuts are
do be shown but there are none), have to figure out how to handle that
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
now to figure out if importing of action collections settings should be
magic or done by a KShortcutsEditor::importConfiguration() call (there is
only one place where it is called, see kwin/kcmkwin/kwindesktop/main.cpp)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
kinda hack tho but makes it easier to distinguish between main and plugin
action collection shortcuts, if there is only one top-level item it should
not be visible (decorated) for cases like kwin KCM but this will be done
later on
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
the idea for QImage/QPixmap-optimized widget occurred to me while
writing kimageviewer (see the kde-playground repo), unlike the widget I
wrote for kimageviewer this one supports drag-n-drop tho and is drop-in
replacement for QLabel when showing only a pixmap is required. the
widget also shows a small image while dragging ala ksnapshot
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
the keycode for invalid shortcuts (QKeySequence) is zero, the key could be
zero if alternative shortcut is not set and there is only primary shortcut.
also, Katie's QKeySequence supports only two key combinations now - one for
primary and one for alternative, see the following commit in the Katie
repo:
d03db175529e800f62acd858badb5622be2e00af
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>
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>
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>
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>
the homepage and the bugs email address shall always be defined in
kglobalsettings header for official Katana applications, libraries, etc.
the option to override them is still a thing
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
QDesktopWidget is Xinerama aware and it can be disabled because I
implemented option for that, see the following commit in the Katie repo:
b7e4bae65f0cae7f3029b98980f638c077ecfc22
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
much like KPasswordDialog which does a lot of focus tricks depending on
its flags and which widgets are to be shown
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
note that it does not change the locale language (yet), nor does is affect
it. it changes the translation language(s) - two different things!
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
to be rewritten. date, time, days, etc. translation and conversion work
like a charm tho (when translated and supported by the locale classes
ofcourse):
https://ibb.co/hcW0dL3
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
by using QLocale in KLocale and separating the date, time and numbers
conversion from translation KLocale actually gets extended locale
support from QLocale (which uses CLDR data v43 currently). translation
remains unaffected. for comparison here is the result of two function
calls the result of which should explain the whole change:
KLocale::allLanguagesList().size() = 669
KLocale::installedLanguages().size() = 68
the first number is locales Katie supports, the second being the
number of languages Katana is translated into
KSwitchLanguageDialog needs a rewrite but that is on the TODO
also copyrighting KCatalog to me because I rewrote it, for reference:
881b47b8ea
KCalendarSystem gets the middle finger - batteries not included for date
and time. extra calendar systems can, but are unlikely to be, supported
in the future
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
interestingly QLocale is not used for many things but that is about to
change, Katie uses it a lot internally (e.g. for QDateTime formatting
and such) so instead of bolting a calendar system on top of KLocale
perhaps a QLocale wrapped around in KLocale will fit the general idea
of using QLocale in widgets when necessary (as does QCalendarWidget).
that however means no way to specify a calendar system (in general,
other than changing the widgets locale itself) but the QDateTime and
related classes are tied to gregorian calendar already - the system
time itself carries no information about the calendar and any
conversions from one calendar to another are basically made up stuff
(there is the time zone thing ofcourse but that is not a calendar)
another interesting thing to note is that KLocale was written such that
it is read-write - changing the date formats for example is possible
because there are public KLocale methods for that.
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>
