KIO slaves are either helper (e.g. vnc/rdp), not source (e.g. thumbnail
which is also helper in a way) or have listing capability (e.g. file
which is filesystem type)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
no .protocol file specifies Capabilities and there are
KProtocolManager::supportsListing(), KProtocolManager::supportsReading(),
etc. capability getters (altought reading multiple config entries is
sub-optimal)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
with klauncher no longer responsible for KIO slave the next step is to
make them plugins and the feature to put them on hold will be of no value
because QLibrary reuses library/plugin instances and creating a new
slave object will be cheap
in other words the performance will be similar to that of KFileMetaInfo
for which I also wrote the plugins myself - they are pretty quick
compared to what strigi was doing and with more flexible configuration
interface but it took some effort to get there
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
KIO was designed around remote protocols and is very much not suitable for
archive browsing for example
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
most of the changes were done trought Katie's namefsck script which
convertes forward class declarations to include directives, however
other fixes here and there were needed as well as some questionable
changes to Q_DECLARE_TYPEINFO() macro calls because they most likely
have to do the namespacing themselfs (QT_BEGIN/END_NAMESPACE, and
probably will be in Katie) meaning that some of the changes may be
temporary and reverted later.
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
