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>
UNIX being UNIX the leading dot meaning a file/directory is hidden is not
going anywhere, the private KFileItem hidden member is always set to
KFileItemPrivate::Auto too
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
KFileItem::mimeTypePtr() is lesser version of
KFileItem::determineMimeType() and if KFileItem::determineMimeType() did
not return valid KMimeType::Ptr then neither will KFileItem::mimeTypePtr()
but calling KFileItem::::mimeTypePtr() after KFileItem::determineMimeType()
is redundant
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
the signal is actually not used, see the following commit in kde-workspace:
45bbcd5e5e963d029974e09fd66edc454e7e9dc4
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
way too much private and mutable KFileItem members, not used a lot so the
performance impact is next to none
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
first thing first - KFileMetaInfo does not support non-local files and
KFileItem is ment to be wrapper for both local and (most importantly)
remote (including virtual KIO) files. KIO::UDSEntry does not carry metadata
either so having a metadata getter and setter in KFileItem is simply
redundant, both are not tested and used only by plasma folderview applet
(see kde-workspace/plasma/applets/folderview/tooltipwidget.cpp)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
when it comes to KFileMetaInfo its bottleneck is determening what plugin to
use for the given URL/path - determening MIME type, matching globs, etc.
and it still is quite fast to the point where the flags are simply
redundant
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
contrary to common sense the KFileItem comparison operator does not compare
the item attributes, only the URL
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
because KDirListerPrivate::unwatchUrl() modifies the list, fixes possible
crash (if the watched URLs list was not empty)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
dolphin for example assumes that signals are emitted only for the filtered
items, not for the root too
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
see 693febf429, and since mount points are
local directories (or rather not a KIO thing) KDirWatch will notify
about the changes when the mount point directory no longer contains
entries
bonus points for reducung the D-Bus traffic
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
one more thing to (possibly) optimize - KDirListerPrivate::_k_slotFileRenamed(),
after that its hammer (test) time and I already have something in mind
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
for the rare case of currently listing remote protocol (such as
filenamesearch:/) and local file that is not watched being deleted (the
signal is emitted by KDirNotify)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
that will only convert it back to QString in the KUrl constructor but it
will not be from UTF-8 bytes - the attribute string is converted to latin1,
duh
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
only for the case when not automatically updating (not adding to the URL
list to save memory and computation)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
