rjvbb added a comment.
Then again, all "not non-gui" applications need an application icon, and adding one is simple enough that it can be done in cmake with a few simple enough operations. And a little bit of extra care in the source code to avoid undoing the effect of ecm_add_app_icon. Adding supported document types in the plist has zero interest if you don't modify the code so it catches Qt's `FileOpen` events or even implement an independent handling of the underlying platform events (Qt's generic interface is limited). That's not any easier than writing a plist (for which Xcode provides an editor that takes care of the XML generation). Let's approach this from the other direction. `ecm_add_app_icon` and (IIRC) ecm_mark_nongui_application both use existing cmake functionality to generate the desired plist file from a template. The template plist contains tokens as the value of a number of important keys. It still becomes a valid plist if you don't replace all of those template tokens (e.g. because a project's build system doesn't provide all the required information). What support does cmake have to add arbitrary XML sections to a template file? Suppose you'd need to create a block (list of sections to insert) and then use that as the replacement for a token that's at the appropriate location in the template plist, which would be the easy approach. What happens that token isn't replaced? The plist wouldn't be formally valid XML, but how would the OS treat such files? I'm not saying it should never be done. I do have my doubts as to the urgency and the return on investment. REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D10808 To: sbragin, #okular, rjvbb, aacid Cc: ltoscano, aacid, rjvbb, #okular, michaelweghorn, ngraham
