[dolphin] [Bug 417069] tab icons of remote urls needs resolving from UDSEntry '.' when available

[Harald Sitter]

https://bugs.kde.org/show_bug.cgi?id=417069

Harald Sitter <sitter at kde.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|plasma-bugs at kde.org         |dolphin-bugs-null at kde.org
          Component|Samba                       |general
            Product|kio-extras                  |dolphin
            Version|20.03.70                    |19.12.2
            Summary|tab of smb:// ioslave has   |tab icons of remote urls
                   |the "unknown" icon          |needs resolving from
                   |                            |UDSEntry '.' when available

--- Comment #4 from Harald Sitter <sitter at kde.org> ---
The bug happens because QMimeDatabase::mimeTypeForUrl is dumb WRT urls

```
If the URL is a local file, this calls mimeTypeForFile.

Otherwise the matching is done based on the file name only, except for schemes
where file names don't mean much, like HTTP. This method always returns the
default mimetype for HTTP URLs, use QNetworkAccessManager to handle HTTP URLs
properly.

A valid MIME type is always returned. If url doesn't match any known MIME type
data, the default MIME type (application/octet-stream) is returned.
```

This is a cost-vs-visual kinda trade off I guess. Inside KIO::iconNameForUrl we
probably shouldn't ask the slave for the mimetype in the interest of speed, but
then we can't get accurate mimetype lookup which sucks.

KIO actually falls back to protocol already, but the if conditions is flawed.
mimeTypeForFile always returns application/octet-stream which always maps to
unknown by default. "i" is then always non-empty rendering the condition
useless

```
        if (i.isEmpty()) {
            i = KProtocolInfo::icon(url.scheme());
        }
```

All that being what it is. There are bugs in multiple places here...

- KIO needs a fix for the condition at the very least

But even then the icon lookup isn't working correctly. As I say, we know this
is a directory, dolphin just needs to put that knowledge to use. 

- Dolphin needs to only use iconFromUrl until listDir has completed. Afterwards
it needs to use the '.' UDSEntry and determine the icon from that
(UDS_FILE_TYPE or UDS_ICON; I think KFileItem abstracts that?).

I'll bounce the bug back to dolphin and deal with the KIO defect right now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.