2.1: backwards compatibility

Everything related to our flagship word processor.
Post Reply
rfwilmut
Posts: 15
Joined: 2013-11-11 04:23:31

2.1: backwards compatibility

Post by rfwilmut »

I have Macs running both Mavericks and Snow Leopard. If I upgrade the Mavericks Mac to NW 2.1 will I have any problems opening files it's created on the Snow Leopard Macs running NW 2.0.7?

User avatar
martin
Official Nisus Person
Posts: 4935
Joined: 2002-07-11 17:14:10
Location: San Diego, CA
Contact:

Re: 2.1: backwards compatibility

Post by martin »

When it comes to exchanging files, Nisus Writer Pro (NWP) version 2.1 is totally compatible with NWP 2.0.x. Nearly any content you create and save to RTF using NWP 2.1 will open properly in NWP 2.0.x, and vice versa. This is true no matter which version of OSX you are using for either app.

The only caveat has to do with links to external files. If you add a hyperlink to some external file using NWP 2.1 it captures a security authorization for the target. This is required under sandboxing so that NWP can persist access to the target. These security authorizations are not understood by NWP 2.0.x and will be discarded, though the link will remain valid. However, if you move a document in the other direction (create a link in 2.0.x and move it to 2.1) the target will be inaccessible, since no security authorization was captured.

I hope that makes sense. Please let me know if you have any questions.

Vanceone
Posts: 168
Joined: 2013-05-03 07:06:31

Re: 2.1: backwards compatibility

Post by Vanceone »

One other significant (indeed, I would say very significant change) for the worse, regrettably, is Nisus lost the ability to do much of anything significant with Applescript. Not necessarily Nisus' fault, as Apple's Sandboxing code means Applescript has been neutered to a great extent. Any macros using Applescript will almost certainly break in version 2.1.

Still, doesn't that mean that if you wish to use Nisus as part of a workflow and other apps, you must move your code out of Nisus into a separate Applescript app, and initiate everything from outside Nisus now. Correct?

Also, does this new version of Nisus mean it will jump on the Apple Store now?

rfwilmut
Posts: 15
Joined: 2013-11-11 04:23:31

Re: 2.1: backwards compatibility

Post by rfwilmut »

Thanks for the answers. Hyperlinks aren't an issue for me, but Applescript certainly is - I have an important workflow using QuicKeys and Applescript and invovling both Nisus and Filemaker Pro, and no wish to spend hours rewriting it...

Presumably both versions are standalone applications, so as long as I hang onto the old version (zipped if necessary) I can try out the new version, and if it doesn't work ditch it and revert?

User avatar
martin
Official Nisus Person
Posts: 4935
Joined: 2002-07-11 17:14:10
Location: San Diego, CA
Contact:

Re: 2.1: backwards compatibility

Post by martin »

Vance is correct that the ability to run AppleScripts from within Nisus Writer Pro (NWP) has been restricted in version 2.1 due to sandboxing. Specifically when running an AppleScript from within NWP, it can no longer interact with any other applications or data outside NWP's sandbox.

This might not be a problem, depending on your AppleScript. For example, if you had an AppleScript that manipulated NWP's document windows, it would still operate correctly. Also, if you run AppleScripts externally (eg: via Script Editor) they will not be restricted, since they are outside the sandbox.
Vanceone wrote:Still, doesn't that mean that if you wish to use Nisus as part of a workflow and other apps, you must move your code out of Nisus into a separate Applescript app, and initiate everything from outside Nisus now. Correct?
Yes, that is now generally correct if you want your AppleScripts to interact with NWP and another application at once.
Also, does this new version of Nisus mean it will jump on the Apple Store now?
NWP is already on the Mac App Store, but sandboxing is a "must" now that Apple mandates it for any new app versions.

Vanceone
Posts: 168
Joined: 2013-05-03 07:06:31

Re: 2.1: backwards compatibility

Post by Vanceone »

It's not necessarily all bad news. The Sandbox restrictions don't eliminate Applescript: they just make it more... challenging.

To expand on what Martin said, and as I understand it:

Basically, any Sandboxed app cannot use Applescript to target another app unless it has entitlements to talk to that app. Most general purpose apps clearly don't sign up for entitlements to all apps under the sun; they have no possible way of anticipating your needs.

But you yourself can write applescripts that target sandboxed apps. So, if your workflow can be something like "when I want this to run, I double click on this app name and it runs" then Nisus and FileMaker and everything else will still work. If, however, you write a macro in Nisus, it will not be able to talk to anything else. It's a question of source: where does the Applescript command come from? If it's from your applescript script, I believe things will still work. Your script calls Quickeys; then calls Nisus, processes the returned data, then sends it to FileMaker-- all of that will still work. If you trigger a QuicKeys and it calls Applescript code that talks to Nisus, then the Nisus Sandbox won't interfere. It's only outgoing calls that originate in Nisus Writer that is hampered by the Sandbox; everything else should still work.

User avatar
martin
Official Nisus Person
Posts: 4935
Joined: 2002-07-11 17:14:10
Location: San Diego, CA
Contact:

Re: 2.1: backwards compatibility

Post by martin »

rfwilmut wrote:Presumably both versions are standalone applications, so as long as I hang onto the old version (zipped if necessary) I can try out the new version, and if it doesn't work ditch it and revert?
That is correct, NWP 2.1 is a standalone version, and you can revert to an older version if you choose. However, there are two caveats to consider:

1. After you first revert to a non-sandboxed version (eg: 2.0.7) you will find that your customizations are missing. That is because all your preferences and support files were migrated inside the sandbox when you first used version 2.1. To migrate them back, please see this FAQ which provides a Perl script to help with the job.

2. Interleaving use of a sandboxed version (2.1) and a non-sandboxed version (eg: 2.0.7) on the same Mac may result in some irregularities. I do it myself, for testing and such, but honestly I've seen OSX get confused about preferences between the two. Nothing major breaks, but sometimes there's some hiccup in some preference I've established.

User avatar
martin
Official Nisus Person
Posts: 4935
Joined: 2002-07-11 17:14:10
Location: San Diego, CA
Contact:

Re: 2.1: backwards compatibility

Post by martin »

Vanceone wrote:Basically, any Sandboxed app cannot use Applescript to target another app unless it has entitlements to talk to that app. Most general purpose apps clearly don't sign up for entitlements to all apps under the sun; they have no possible way of anticipating your needs.

But you yourself can write applescripts that target sandboxed apps. So, if your workflow can be something like "when I want this to run, I double click on this app name and it runs" then Nisus and FileMaker and everything else will still work. If, however, you write a macro in Nisus, it will not be able to talk to anything else. It's a question of source: where does the Applescript command come from? If it's from your applescript script, I believe things will still work. Your script calls Quickeys; then calls Nisus, processes the returned data, then sends it to FileMaker-- all of that will still work. If you trigger a QuicKeys and it calls Applescript code that talks to Nisus, then the Nisus Sandbox won't interfere. It's only outgoing calls that originate in Nisus Writer that is hampered by the Sandbox; everything else should still work.
This is all exactly spot on. Thank you for adding that very nice clarification!

Post Reply