| Summary: | (probably) undesirable file type check through file extension | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] kdelibs | Reporter: | David <spamaccountmeister> |
| Component: | general | Assignee: | kdelibs bugs <kdelibs-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | andresbajotierra, faure, niels.misc, Regnaron, rrh, tanuva |
| Priority: | NOR | ||
| Version: | SVN | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Attachments: | File attachment | ||
|
Description
David
2009-03-28 20:21:14 UTC
Thanks for the report. The file extension has a higher priority as the content of a file. So if you you rename a text-file to a .pdf file, Okular will get opened and this is the expected behavior. Only if there is no file extension, KDE will try to guess the file type by looking into the content (this is quite expensive, as the file needs to get opened twice: once for determining the content, a second time by the application that should show the file). So if you have a text file without text extension, still the text editor (kwrite, ...) will get opened. The current behavior is equal to the behavior of KDE 3. I'll close this bug as WORKSFORME (please let me know if I misunderstood your request). Hi, you understood perfectly. The only thinh is that the behaviour you explain (the expected one) sometimes doesn't really happen. I experienced this with a simple text file without any extension. Thanks for your reply David, could you maybe attach this text file to the bug report? I did some tests with text files having no extension and KWrite has been opened as expected in my environment... (Update: The submitter of the report sent me the text file where the autodetection does not work - I could reproduce the issue in KDE 4.2 and trunk. When using the same file in KDE 3 with Konqueror, it is noticed as text file) I've set David Faure to CC. This might be an issue with the used encoding of the text file and this report should go into kdelibs. @David (bug-report submitter): I know the text file you've sent me contains some names of your friends (-> that's why it is not attached here). Would it be possible to modify the names of this file and attach the file here? Otherwise it will get tricky to fix this issue. Thanks! Created attachment 32826 [details]
File attachment
Hi again
I'm really convinced it is the enconding. If I use characters such as "é" the file type is not correctly identified.
Cheers
SVN commit 970853 by dfaure: shared-mime-info says "note that files with high-bit-set characters should still be treated as text since these can appear in UTF-8 text, unlike control characters" and that was the intent of the code; but the 127-255 range was treated as signed, so negative, so < 32 -- so text files with accents in them weren't recognized as text. BUG: 188355 M +1 -1 kmimetype.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=970853 *** Bug 173370 has been marked as a duplicate of this bug. *** *** Bug 189660 has been marked as a duplicate of this bug. *** *** Bug 193958 has been marked as a duplicate of this bug. *** *** Bug 124757 has been marked as a duplicate of this bug. *** SVN commit 990397 by cfeck: Let Qt render text thumbnails We used a tiny bitmapped font which was unfortunately lacking any non ASCII characters. We now detect non ASCII files as text files, so we should render them better. This code uses the smallest readable font, but currently forces it to a very small pixel size (similar to what the old code used). The text encoding detection might need some improvements, e.g. use the default locale encoding, when the prober is not very sure. Reviewed by Peter Penz Reviewed by Darío Andrés See http://reviewboard.kde.org/r/760/ BUG: 169381 CCBUG: 188355 M +0 -1 CMakeLists.txt M +39 -112 textcreator.cpp M +0 -3 textcreator.h D thumbnailfont_7x4.png WebSVN link: http://websvn.kde.org/?view=rev&revision=990397 |