does it as like overlay and basically the blended icon overlaps with any
other icon overlay (e.g. the one from KIO::pixmapForUrl()), on a side note
the overlays are placed well (visually) because the offset is fixed rather
than a factor (1 pixel offset)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
normally that would never happen, however if kioclient is used (e.g. in
attempt to list https://foo.bar.baz.com as if it is directory) then it
can happen
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
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>
