Created attachment 129708 [details] Registry patch I use Okular distributed on Windows Store on my Windows 10 OS. Upon installation **and updates** Okular sets its filename extension associations to only a handful of formats. It is in fact able to parse many more formats but limitations of Windows Apps platform, subject to Windows Store, make it impossible to open any arbitrary filetype in Okular straight from OS without first launching Okular and using its "Open" dialog. Note, that trying to associate an "App" installed through Windows Store using the legacy OS "Open with" dialog just does not accomplish anything other than leave you with a registry mess to clean up if forced. I had to resort to writing my own registry patch (attached) to add all supported associations bindings (and some that seem underdeveloped in the Windows build, but it doesn't hurt anyway). If you take a look at the attached registry patch, note that only the first key with its many values (first 60 lines) is required — rest is just for extended support and can be omitted AFAIC. Also note, that key name (path) includes the version string. Now for the meat of the issue: not only do I have to reapply the registry patch on every update, but I also have to edit it in accordance with the new version string every time. I could write a script to heuristically accomplish this for me but it doesn't feel like it's too much to ask you, as developers, to instead open the whole array of associations by default or at least give me, as a user, an option to enable further filename extension associations.
Is it possible that Okular sets only some obvious extensions (like .pdf, .epub, .okular), and you are missing extentions like .png, which are usually better handled by other applications? My memories of configuring standard applications was that Windows will refuse to open files with other applications afterwards. (I am currently not a windows user.) Is that still true? If so, installing Okular with all filename extensions would cause serious trouble to most Windows users. Or can an application mark these extensions as something like optional?
(In reply to David Hurka from comment #1) > Is it possible that Okular sets only some obvious extensions (like .pdf, > .epub, .okular), and you are missing extentions like .png, which are usually > better handled by other applications? > > My memories of configuring standard applications was that Windows will > refuse to open files with other applications afterwards. (I am currently not > a windows user.) Is that still true? If so, installing Okular with all > filename extensions would cause serious trouble to most Windows users. Or > can an application mark these extensions as something like optional? Oh, I see what you mean. In short, no, your assumption is fully incorrect. There are many different techniques the Windows operating systems, starting from at least Windows XP (but probably even Windows 95), employ in unison to keep cross-referenced tables of available associations, allow assisted manual altering of those and full flexibility. Basically, it largely follows the model of "open with..." + "remember?". Bears mentioning that Windows OS almost never deals with file headers, rather it relies on filename extensions instead. Header reading can be implemented by programs themselves in their own runtime if at all. So when I say "filetype" I mean "filename extension" from the point of view of the OS. Filetype associations should be thought of as simple pairs of __full executable path__ + __extension string__. Additional CLI operands inclusion is possible but not UI-assisted. It's a rare enough requirement which programs that need it usually handle themselves. Each filetype ends up having a compiled list of registered associations available and optionally, one of them is set as primary for quick opening. In user experience it boils down to these options: - Quickly open a file with the primarily-associated program by double-clicking the file in Explorer GUI or in CMD command prompt with commands like `start` and other proxies for ShellExecute. - Open a file with an added step of choosing a program to open it with, from a list of known supported associations for the given filename extension or manually add a new one to the list by pointing to an executable to be associated with this filetype. - Pick the primary association between a filetype and a program to be used by default for quick opening, with or without immediately opening a given file. Additionally: - If the filename lacks an extension, thus the OS cannot determine the filetype, — the user has to pick a program from a special extension-less associations list or manually add a new one. No primary can be set. - If there is no known association for a given filetype, the user is also promted to manually add a new one. IIRC, that association automatically becomes primary for being the only one. - Naturally, if there is only one association for a filetype — it is treated as a primary for quick opening. - (Kinda new feature) If a new association (2nd and so on) is added for a filetype outside of association UI (e.g. upon a relevant program installation), the primary association for that filetype is unset and the user gets prompted to pick a primary association upon next opening of that given filetype. Programs can announce their supported filetypes list upon installation and/or in runtime. That list is factored into complete list of association options available to the user for opening files. But, on top of that, there is also a special configuration menu in Windows that allows the user to see these lists of registered filetype associations **per program** (as opposed to filetypes) and decide if any or all of those should be set as primary. The **basics** of all this should sound very familiar if you're used to Android OS, which, and I can only assume this, was mimicking Windows in this regard. The flexibility is lacking on Android, of course, since one cannot manually set an association or open a file with a non-primary association without unsetting the primary first in the OS UI. But Okular is distributed through Microsoft Store as a Windows App instead of a loose executable, an executable installer or an MSI package. And the thing with Windows Apps subsystem is that it is conversely trying to mimic the limitations of Android to enhance portability and security. Windows Apps live in their own sandbox only partially integrated with the "legacy" OS toolset. **There is no option to manually add an association** without hacking one in through Windows Registry editing but that gets reset on each Okular update. Thus, it is imperative that this version of Okular announces all of its supported filetypes upon installation or the Windows OS will never provide the **option** to open them in Okular. If Okular does announce its full list of supported filetypes — not only the user will be prompted to switch to Okular **or stick with the former primary association** for a given filetype upon trying to open one, but they will also always retain the ability to change their mind any number of times.
Hi if your interested in extending the default associated files, feel free to fill in the mime types and extensions in here https://invent.kde.org/packaging/craft-blueprints-kde/-/blob/master/kde/applications/okular/okular.py#L53
(In reply to Hannah von Reth from comment #3) > Hi if your interested in extending the default associated files, feel free > to fill in the mime types and extensions in here > https://invent.kde.org/packaging/craft-blueprints-kde/-/blob/master/kde/ > applications/okular/okular.py#L53 The list already has to be somewhere in the codebase, since the Windows build comes with one used for internal operation. Okular must be passing it to the OS shell when creating its "Open file" dialog — the dialog lists all of the supported extensions for filtering. That's where I ripped them from for my registry patch. And then I added *.txt on my own, which was not listed for some reason. Here's a screenshot: https://i.imgur.com/lcDWUeQ.png I could format that list to your language and code style, reference corresponding mime types, maybe even test if each of them works nominally on Windows. But... 1. It would be kind of a waste to duplicate something that's already somewhere in the codebase. 2. I'd hate to go through the whole rigamarole of creating a local GitLabs Community account, cloning the whole repo to edit 2 strings and then pull requesting... Do let me know if you can't locate the existing list that's somewhere out there already. I'd look for it myself, but I'd just get lost in the vast KDE codebase. And would it be fine if I just sent a formatted list in a letter, releasing any rights I could have for it, so you can slap your lovely GPL2 on it?
Here: self.defines["file_types"] = [".bmp", ".cb7", ".cbr", ".cbt", ".cbz", ".chm", ".dds", ".dib", ".djv", ".djvu", ".doc", ".dvi", ".eps", ".epsf", ".epsi", ".epub", ".exr", ".fb2", ".g3", ".gif", ".hdr", ".icb", ".ico", ".jp2", ".jpe", ".jpeg", ".jpg", ".jpg2", ".mng", ".mobi", ".odt", ".okular", ".oxps", ".pbm", ".pcx", ".pdf", ".pgm", ".pic", ".png", ".ppm", ".prc", ".ps", ".psd", ".rgb", ".tga", ".tif", ".tiff", ".tpic", ".txt", ".vda", ".vst", ".wwf", ".xbm", ".xcf", ".xpm", ".xps"] self.defines["mimetypes"] = ["application/epub+zip", "application/msword", "application/oxps", "application/pdf", "application/postscript", "application/vnd.comicbook+zip", "application/vnd.ms-htmlhelp", "application/vnd.oasis.opendocument.text", "application/vnd.palm", "application/vnd.visio", "application/x-cb7", "application/x-cbr", "application/x-cbt", "application/x-dvi", "application/x-fictionbook+xml", "application/x-mobipocket-ebook", "application/x-wwf", "image/bmp", "image/fax-g3", "image/gif", "image/jp2", "image/jpeg", "image/png", "image/tiff", "image/vnd.adobe.photoshop", "image/vnd.djvu", "image/vnd.djvu+multipage", "image/vnd.microsoft.icon", "image/vnd.zbrush.pcx", "image/x-dds", "image/x-eps", "image/x-exr", "image/x-portable-bitmap", "image/x-portable-graymap", "image/x-portable-pixmap", "image/x-rgb", "image/x-tga", "image/x-xbitmap", "image/x-xcf", "image/x-xpixmap", "text/plain", "video/x-mng"] Compiled these lists based off the one that already comes with the Windows build. Didn't test much yet. A bit unsure about "application/vnd.palm". I hereby release any and all rights to this work. No rights reserved. Everyone and anybody is welcome to reuse and license it however they want.