Undocumented MacOS X Deployment Options

LiveCode is the premier environment for creating multi-platform solutions for all major operating systems - Windows, Mac OS X, Linux, the Web, Server environments and Mobile platforms. Brand new to LiveCode? Welcome!

Moderators: Klaus, FourthWorld, heatherlaine, kevinmiller, robinmiller

Post Reply
icouto
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 92
Joined: Wed May 29, 2013 1:54 am
Location: Sydney, Australia

Undocumented MacOS X Deployment Options

Post by icouto » Sun Aug 26, 2018 12:51 am

Hi all! I'm trying to understand the deployment options that we have available for MacOS X, in the 'Standalone Application Settings' dialogue - but I'm getting stuck. There seem to be options that are not documented anywhere (I've looked through the User Guide, online docs, lessons and tutorials), but nothing.

So, I thought I'd try the experts here at the Forum:
  • In the PLIST section of the dialogue, there is a field titled 'Signature' (under a 'Name' field), with a default value of "????" in it. What is it? Is this related to code signature? Do we have to manually produce a code signature?
  • Still in the PLIST section, we have a 'Document Type' field, and a 'Document Extension' field. I'm guessing that 'document extension' should be a list of 3- or 4-letter extensions that my app is supposed to support, correct? - e.g., 'txt', 'gif', 'jpg', 'jpeg', etc. But what about 'document type'? Are there pre-defined values that should go there? What about if I want my app to support its own custom document type? - e.g., 'abcd' extension for "ABCD Document'?
  • There is a field at the top of the dialogue for 'Application Icon' and under that one for 'Document Icon'. What happens if my app produces more than one type of document - which should have different icons? Do I have to then manually open the PLIST and edit values directly?
Any guidance is truly appreciated!

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5791
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Undocumented MacOS X Deployment Options

Post by jacque » Sun Aug 26, 2018 10:14 pm

icouto wrote:
Sun Aug 26, 2018 12:51 am
  • In the PLIST section of the dialogue, there is a field titled 'Signature' (under a 'Name' field), with a default value of "????" in it. What is it? Is this related to code signature? Do we have to manually produce a code signature?
This is a remnant of OS 9 where app signatures needed to be registered with Apple. That was abandoned in OS X, so you can leave the default ???? in there. It is still possible to assign a signature if you already have one for the app, but OS X looks at the extension first and doesn't use the signature unless all else fails.
  • Still in the PLIST section, we have a 'Document Type' field, and a 'Document Extension' field. I'm guessing that 'document extension' should be a list of 3- or 4-letter extensions that my app is supposed to support, correct? - e.g., 'txt', 'gif', 'jpg', 'jpeg', etc. But what about 'document type'? Are there pre-defined values that should go there? What about if I want my app to support its own custom document type? - e.g., 'abcd' extension for "ABCD Document'?
The document type is similar to the app signature, a four-character type code used by OS 9. It can be blank or ???? (all types.) The extension is how OS X identifies which document types your app can use. You would list those here. If you have a custom document type, put that extension here instead and be sure your app writes files with that extension. Extensions can be longer than 4 chars, LC uses ".livecode" for example.
  • There is a field at the top of the dialogue for 'Application Icon' and under that one for 'Document Icon'. What happens if my app produces more than one type of document - which should have different icons? Do I have to then manually open the PLIST and edit values directly?
Yes, but you can't edit the plist after you've built the standalone because that will destroy the security signature. Instead, copy the plist and edit it in a text editor, then include it in Copy Files. The standalone builder will use your edited copy instead of its default one. I believe if you are using standard formats like PNG, TXT, etc, you don't need to include icons for those because the OS already has them. You only need the ones that are unique to your app.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

icouto
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 92
Joined: Wed May 29, 2013 1:54 am
Location: Sydney, Australia

Re: Undocumented MacOS X Deployment Options

Post by icouto » Mon Aug 27, 2018 12:20 am

Thank you for your wonderful guidance, @jaqcue! Just to confirm: if I'm not at all concerned with OS 9, I can safely leave the 'signature' and 'document type' fields alone, and all should work fine in OS X?

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5791
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Undocumented MacOS X Deployment Options

Post by jacque » Mon Aug 27, 2018 1:10 am

Right, you can ignore those fields.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

thatkeith
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 317
Joined: Mon Mar 01, 2010 7:13 pm
Location: London, UK
Contact:

Re: Undocumented MacOS X Deployment Options

Post by thatkeith » Wed Dec 09, 2020 10:33 am

jacque wrote:
Sun Aug 26, 2018 10:14 pm
Yes, but you can't edit the plist after you've built the standalone because that will destroy the security signature. Instead, copy the plist and edit it in a text editor, then include it in Copy Files. The standalone builder will use your edited copy instead of its default one.
Reviving an old thread as it seems to be utter gold, and I just want to check a detail...

So should I copy the ENTIRE plist data from a standalone, add <string>jpg</string> (for example, to open .jpg files) between <array> and </array> for the CFBundleTypeExtensions key, save that as a new text file with .plist as the filename suffix, and include that in Copy Files for my new standalone? This seems necessary if the standalone builder will use this rather than make its own.

The info at https://lessons.livecode.com/m/4071/l/1 ... le-onto-it is helpful but not fully clear. (It also doesn't warn users about the security signature issue.) Your comment implies that I need to provide the entire plist data, not just the customised <dict> ... </dict> structure that is shown in that above LC lesson. Also, looking at the plist data from an existing standalone, it appears that I just need to add my <string>SUFFIX</string> line between the existing <array> and </array> of the CFBundleTypeExtensions key.

If this is correct I have one further question: to add more file type extensions do I simply make additional <string>SUFFIX</string> entries?

k
Senior Lecturer, LCC (University of the Arts London)
Technical Editor, MacUser (1996-2015)
360 VR media specialist

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5791
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Undocumented MacOS X Deployment Options

Post by jacque » Wed Dec 09, 2020 6:36 pm

Yes, you've got the right idea. Create a new revised file and put it into Copy Files. I generally edit the whole file. LC allows you to create a file that includes only the changes for an Android manifest but I'm not sure if that also applies to plist files so I play it safe and just use the whole thing.

Can't answer how to include more file types but your idea seems reasonable. Google probably knows.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 5266
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: Undocumented MacOS X Deployment Options

Post by richmond62 » Thu Dec 10, 2020 7:54 am

If you are concernced with Mac OS 9 you won't get very far with recent versions of LiveCode,
so the standalone build settings need a bit of tidying up.

Post Reply

Return to “Getting Started with LiveCode - Experienced Developers”