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>
same thing (all URL components are compared) except the trailing slash
option can be re-used for it essentially adding one more option (to add
trailing slash when comparing)
also fixed and tested KUrl::upUrl() for some cases
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
was used to pass the referrer and while it is still possible to
reimplement it realisticly speaking it is impossible to preserve the
referrer (and other HTTP(S) header metadata) because it will be lost in
transition in some cicumstances such as when drag-n-drop is done to
application unaware of application/x-kio-metadata
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
QUrl::StripTrailingSlash removes all trailing slashes and KUrl does not
convert to percentage encoding - local file URLs remain the same when
passed around.
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
was used only by klipper, also a program writing something ment for
stderr to stdout (and vice versa) is doing something wrong already
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
also not storing the host name because it serves no real purpose other than
being a possible source of problem (hostname change?), copyrighting it to
me because there is nothing relevant left of the original implementation
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
