[okular] [Bug 423560] [Windows Store] Filename extension associations and updates resetting them

[Beybalaev Murad Felixovich]

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

--- Comment #2 from Beybalaev Murad Felixovich <gness.na at gmail.com> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.