because it returns only one (definitive) format type using QStringList as
return type makes no sense, also a mode argument is very much required to
return correct result - not all image format plugins support writing
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>
to avoid conversion from QString to QByteArray when possible, the trace is
handled as array of latin1-encoded strings anyway
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
a crashed program trying to restart itself is very unreliable,
especially program that uses KUniqueApplication instance. so, instead
all the information about the crash shall be written to a file on the
disk (in the temporary directory) and read by external kcrash KDED
module that will report the crash (possibily even upload the crash
details somewhere) and restart the program as necessarry.
this also opens up possibility for per-application configuration for
things such as the automatic restart feature but that shall be done by the
kcrash KDED module instead (parsing a config from a crashed program is
not a good idea)
KCrash::NoRestart will be unused but kept for future expansion
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
the plasma frame applet for example uses zero time (QTime(0, 0, 0), not
invalid time) as a special for case for "never" (i.e. don't update) so
having this feature will make KTimeEdit even more suitable for timers (that
ofcourse has to be handled by the application or library, zero time timers
are a thing)
also min/max now allows to set lower seconds (for example) when the minute
is not zero instead of just restricting the seconds value to a hard-minumum
altough that makes me think a step feature may be needed (e.g. to now allow
intervals less than two seconds with minimum of one second)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
the signals come from the locale KCM however applications, libraries and
widgets handling of such changes is mixed - some do it on
QEvent::LocaleChange, some on QEvent::LanguageChange, some when the
KGlobalSettings signal is send so sending the events will make sure that
locale changes take effect immediatly (when and wherethe event is watched
for ofcourse, KCalendarWidget does it for one)
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>
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>
because the details widget may be shown, the dialog manually resized and
when the details widget is hidden the manually set size gets overriden -
the dialog size should remain the same after manual resize!
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
essentially moving my code from the old networkstatus module, see the
following commits in the kde-workspace repo:
809b90a113bb559a94266464e03cba6f0ed197ae
c46a5297cc49bf4f19f81ee109833fb0abab9a99
3e01d82f44bf587251455368f7502e9e4e204176
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
