D10808: Implement the generation of a custom Info.plist for the Mac OS bundle

[René J.V. Bertin]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/okular-devel/attachments/20180225/c9ec01fb/attachment.html>