rjvbb added a comment.
My original implementation is used in conjunction with a build system that
ensures all dependencies are available.
I don't know if cmake is flexible enough to add the XML elements for the
document types that a local build will support given the locally available
dependencies, without having to generate the entire file from within a CMake
file. The functionality present in the ECM uses a template file containing
tokens (variables) that are replaced with the appropriate strings during the
configure phase. The task at hand seems more complex and I have my doubts as to
how worth it would be the effort to implement support for doing this in the
ECM. I'd say there are Mac-specific things that should be higher on the list.
In case of Okular one could think of printing a big CMake warning (on Mac),
or even let CMake fail by default if all dependencies implied by the plist file
are not available.
Note that this just tells LaunchServices what an application can or could do.
It does not in any way modify anything else, in particular it won't change the
application the system will use to open a document type it already knows how to
open. Also note that we're not talking about a platform where distribution
systems packages broken down in fine-grained bits and pieces and where you can
easily end up with a partial Okular install.
If Okular's capabilities depend on the availability of plugins which might be
installed independently then the current implementation is acceptable and
comparable to Apple's own policies with e.g. QuickTime Player (which at least
in the past would often tell the user that it needed additional components to
open a given video file). Annoying for common file types, but competely moot
for filetypes you won't ever encounter.
Finally, Kate and Kdevelop follow the same "hard-wired" principle, the former
using a wildcard solution ("this app can edit anything"). Not optimal maybe,
but not a true issue for applications that the user either installs from an
official all-inclusive app-bundle download, or using MacPorts or HomeBrew
packaging, or else from a manual build-from-scratch.
REPOSITORY
R223 Okular
REVISION DETAIL
https://phabricator.kde.org/D10808
To: sbragin, #okular, rjvbb, aacid
Cc: ltoscano, aacid, rjvbb, #okular, michaelweghorn, ngraham
