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>
this was not done in the previous implementation but it is now, it will
allow to detect tzdata changes and fallback to UTC in the plasma time
data engine during system upgrades for example. that ofcourse is only
theoretical and preperation for worst-case-scenario type of situation but
good to have anyway
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>
if KMimeTypeRepository::findMimeTypeByName() did not find the default MIME
then another lookup that does the same as
KMimeTypeRepository::findMimeTypeByName() will not find it either
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>
it is singleton and essentially the parsing of aliases, subclasses and
magic files has to be done only once during the entire program lifetime so
rathern then locking and blocking from getters do it in a fire and forget
fashion
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
kcfg files are resources much like .ui files - not ment to be installed,
used only to generate .cpp and .h files from them. they are not used at
runtime altough Plasma::ConfigLoader does use its format to load files
for configuration purposes (files named main.xml shipped by plasmoids)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
to replace the status notifier (in the kde-workspace repo) and
eventually manage network connections aswell as move network status
notifier out of solid
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>
