SUMMARY If a PDF is saved or renamed without the .pdf suffix it will not be shown by the default setting of the File Open dialogue. STEPS TO REPRODUCE 1. Save a file without the .pdf suffix 2. Click File->Open or press Ctrl+O 3. If necessary select "All Supported Files" OBSERVED RESULT The file is not shown for opening EXPECTED RESULT The file should be shown as it is supported. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 5.18.5 (available in About System) KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.70.0 Qt Version: 5.12.7 ADDITIONAL INFORMATION
Please explain how this can not be a bug. PDF is a supported format. A PDF file is therefore supported, so why should it not be shown as such? Closing "Not a bug" without explaining why is unhelpful. Why is this not a bug? Only a Windows user would think this not a bug. It can't be intentional behaviour because it makes no sense. Linux does not identify file types by name or suffix.
It's not a bug because it's not a bug, a bug is "i wanted to print and instead it kick me in the face" At most it's a missing feature. "Linux does not identify file types by name or suffix." Prove it, give me a graphical program that will do what you say.
The GIMP.
oh, seems like gtk, supports adding mimetypes to the file dialog, Qt just supports adding file extionsions. There's nothing Okular can really do here.
Interesting. So this is less a Windows/Linux issue and more a QT/GNU one. Two fundamentally different approaches to identifying files only exposed when someone with one understanding encounters behaviour originating from the other. The only question now is how to close this. From the QT perspective it's not seen as a bug because this is QT's intended behaviour. From a GNU perspective it's a fundamental flaw in QT which applications can't fix, so needs a can't fix/won't fix response (which is not available here). It's hardly resolved, but can't be resolved. An interesting journey, though. Thanks for getting to the bottom of it.
You really need to tone done your answers, don't speak as if you where the harbinger of what is or is not GNU. Anyhow, i was wrong, Qt actually supports giving mimetypes, we just need to make Okular use that feature. If you had been a bit more polite, i'd put it a bit higher on my TODO list
I'm sorry if I came over as arrogant. That was certainly not my intention. I was upset by the summary and unexplained nature of the closure as "not a bug" and the response when I asked for an explanation. Expectations vary in the software and Internet worlds. I often explain it as governed by "rules made by anarchists" in the sense that there are no actual rules. Most Internet protocols are not officially standards but Requests for Comment although, in practice, and RFC actually has to go through a fair amount of peer review to become a recognised RFC. In the same way, in the Free Software world (or should that be Open Source?) there are many interpretations of how and why things ought to be. The distro I use, for instance, is adamantly opposed to systemd, because it breaks the one program for each function principle some consider essential to UNIX. So far as I know, no one has actually defined such a rule; it's just an understanding that has grown up among a certain subset of users and gets reinforced by agreement among those subsets. These expectations are often deeply held, and can cause clashes when questioned, simply because there are no rules, and therefore no arbiter to whom one can appeal, so robust statements of what is assumed to be true (but can never be proved) tend to become dominant and tribal loyalties can form around them. However, it does seem sensible to me that a file which conforms to the specification a program is intended to open should be considered a supported file, and unless that specification includes a naming requirement the name should not be the basis of such an identification. The issue for me is that my bank makes PDF statements available for download, but gives them all the same generic name, so I have to rename them. Since they are stored in a directory which is only used for storing PDFs I saw no point in adding ".pdf" to the end of all the new names, as that told me nothing I didn't know and would de-emphasise the distinctive part of the name identifying the individual statements. When I went to open these in Okular, leaving the filter set at the default "All supported files" I couldn't see them, and it was tedious to have to change the filter every time I wanted to open a different statement, and since they appear to be supported files I considered this enough of a problem to be worth reporting. It never occurred to me anyone would think this intended behaviour. I appreciate this comment adds nothing to the bug, but it seems that the offence I took has also given offence, which was not my intention, so I must apologise for that.
A possibly relevant merge request was started @ https://invent.kde.org/graphics/okular/-/merge_requests/232
Git commit 04d92f5847d15110e8691ba2510f61253123ea7f by Albert Astals Cid. Committed on 28/08/2020 at 21:56. Pushed by aacid into branch 'master'. File dialog: Use mimetypes instead of file extensions Only if you're on a new enough KIO, we need a1acb7744455b57dc972b3073f6e1dce0d49d965 and 7bf4d793a5ac54280c45660dbd04de4fa99dc994 present since 5.73 to make the UI usable M +12 -0 shell/shell.cpp https://invent.kde.org/graphics/okular/commit/04d92f5847d15110e8691ba2510f61253123ea7f