because KFileItem::refresh() throws away the KIO::UDSEntry, KMimeType and
other info on refresh the only way to get back that info is to list the
directory again for non-local items
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
if the slaves do not know what URL is being stat()-ed, listed, etc. then
what? this may make the URL different than the one originally requested (as
it should be) in case of redirection(s) for example
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
kde-open does exactly the same - it calls
KToolInvocation::startServiceForUrl() with the URL as argument
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
tested with dolphin file search slave, more hammering will be done in the
future
for reference:
https://ivailo-monev.atlassian.net/browse/KDE-20
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
as the RFC says - the server (KHTTP in this case) can ignore range
requests, tested with curl and wget and both will not get a range transfer
but the request will not fail because the server does not support ranges
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
otherwise the icon does not match the one that dolphin shows for example,
not to mention KMimeType::findByUrl() can only guess from the name for
remote URLs instead of using the info KFileItem already has
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
no other way to figure out the MIME type (reliably, could be guessed from
the name but that is not exactly accurate guess)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
none of the bits actually belong there but KIO was designed in such a way
that it is not part of kdecore and as such KMimeType::iconNameForUrl() will
have to handle the cases for KIO (except overlays maybe)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
KRun did not do that, it is done now tho and (essentially) instead of
starting the service for inode/vnd.kde.service.http (which there is no
registered service for, that MIME type is made up for the sake of KIO)
the service for the target URL (e.g. http://192.168.1.100:12216) will be
started (which since that is http service would be most likely web browser)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
more conditions are added into the mix but that is how it should be,
KMimeType::iconNameForUrl() barely covers some cases (no overlays?)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
convenience method, was not applying all possible overlays nor was it
producing a pixmap that would match the icon returned by
KFileItem::iconName()
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
was used by some slaves (e.g. the archive slave which is no more).
lets see if you can find it jira:
https://ivailo-monev.atlassian.net/browse/KDE-12
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
NOTE: this is potentionally dangerous thing to do because KLauncher reaps
processes and there is no interruption point for it right now which is one
of the reasons upload confirmation is not in place (user interaction will
have to be potentionally canceled too)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
unused, tho the svg that it paints is used in multiple places as base.
perhaps the class was not flexible enough?
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
