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>
as noted in de7070d2bb having multiple
languages and matching the correct one for each use case will have to be
tuned
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
the fix is only for non-local file URLs, KUrl already does the correct
thing by stat()-ing local file URLs (see KUrl::upUrl())
trailing slash is added to the URL by
KUrlNavigator::Private::updateButtonVisibility() too before checking if it
is possible to go up which essentially means that KUrlNavigator was not
ment to be for files (it does not autocomplete files either) even tho it is
possible to open file by adding file name manually to the URL (via dolphin
anyway, not via KFileDialog tho)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
other than having it around to track what entries kdeglobals has
there is no other purpose for it, I can just use the grep.sh script
from the main Katana repo to look for kdeglobals config references tho
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
default as in no explicit language has been passed as argument to KLocale
and the language comes either from config or the environemnt variables
with this change KCalendarWidget properly adapts to KLocale config change,
however other applications and widgets may not which is something that has
to be looked into. note that logout is (and was before the KLocale rewrite
even) recommended by the locale KCM for the change to fully take effect
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>
otherwise KLocale::formatNumber() has to guess the precision that was
passed to KLocalizedString::subs() and make up a localized integer string
with a magic wand, the precision for precise number types (e.g. ulong,
qlonglong, etc.) remains -1
fixes KSignalPlotter test case failure
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
