abra-code
commented
5 years ago Upon closer look, there are some OMC env variables which trigger different functionality if they are present (nav dialogs, text input dialogs). They cannot be exported when not present and must be excluded. Also, a nib control variable to obtain the content from the whole table view is potentially costly and should be avoided (selected rows should be OK). There are also some variables rarely used and of lesser value which would incur unwanted cost to export them. With this in mind we can identify a core set of variables which will always be exported and will satisfy 99% of needs and leave out the rare/costly/dynamic ones. It would be an unfortunate inconsistency but I guess this is the best we can do. This is driven by pragmatic usage of OMC engine to simplify development. We should clearly document the "core" ones which are always exported.
Currently OMC engine scans the script to see which special environment variables are used and exports only these. This was meant to be perf optimization but it is premature optimization adding unnecessary complexity. If you have a script in the external file, OMC engine never scans it and you need to add the used env variables explicitly. The current idea is to always export all known env variables, which should not be expensive. This is especially important for the planned exe_script_file which would not contain the body of the script in the plist