more accurate probing then before, notably by probing the file content
from the file slave (only the name was checked before because the
filepath was not a full path in some cases and the file could not be
open)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
after changes to multiple sub-projects (Katie, kdelibs, kde-workspace
and kde-extraapps) that finally happened, can write lots about it but I
will keep it short - by rewriting parts that were using js/qml (e.g. the
plasma applets) the desktop startup was reduced to half, also the legacy
tray thing shall be no more (anything that needs tray icon shall be a
plasma applet now) thus some applications and features will be dropped
aswell. see all repositories for the changes done
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
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>
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>
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>
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>
checking for directory existing via QFile::exists() is bogus, also Katana
does not install files in such directory
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>
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>
also adjust KLocalizedString test case, "Job" is no longer translated
string in the source code thus not in the french translation
on a side note there are KLocale tests all around - KLocalizedString, KIO
tests, etc. so perhaphs only quircks should be tested by the KLocale
specifiec tests
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
while the threads are running the kdelibs4 catalog may or may not get
removed resulting in a race and different results in the functions (if
the catalog is not there there will be no translation but the test
functions expect it to be translated when french translations are
installed)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
people really messed up the precisions, look at what kcalc does with the
constants:
kde-extraapps/kcalc/kcalcdisplay.cpp
zero precision is essentially rounding the constants! also setlocale() no
longer has effect on Katie and thus Katana so updated the method to
override locale in KLocalizedString test while at it (tests pass after one
adjustment for the french locale case)
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>
additional calendar systems can be supported via ICU in the future but
for now that will be more than enough considering other things such as
QDateTime and QCalendarWidget, the gregorian and julian calendars being
common, etc.
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>
while it does not matter for comparison, for KUrl::setFileName() to produce
correct results it has to be there after KUrl::upUrl()
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
