Python Scripting Feature Request

I know very little about the details of this but, as a user, I know what I want. :slight_smile:

I would like to be able to script Scrivener in Python. I supposed many programmers more experienced in the Microsoft software ecosystem would likewise ask for support of Microsoft’s Active Scripting interfaces. And the existing Apple folks are looking forward to 2.2 on the Apple side to add Applescript.

So this is a request to add Python scripting abilities. What should the script interface have access to inside Scrivener? For now I’d say look at the Apple forum and note what the Applescripters have asked for.

I’m not going to ask for Perl or Tcl because, although I have used both professionally, I personally much prefer, and am much more productive in, Python.

And if the issue comes up, if it were my decision to make, I would only officially support the ActiveState implementations of these scripting languages.

I love Python, so while I like this, I feel compelled to point out that it’s still a minority scripting language for the Windows crowd.

If Scrivener for Windows exposes a COM interface (yes, I know) then any scripting language that can interop with COM (in Windows, that’s pretty much all of the actually useful ones) can interact with it. And enterprising programmers can then write nice wrappers in Language X for people who use that language and don’t want to deal with COM.

(Myself, as much as I like Python, I use PowerShell these days. It’s the de facto standard for future native Windows administration.)

G’day KB and others!

I would be very much in favour of adding scripting support to Scrivener so that users of this wonderful software package can add their own functionality (including myself, using the Windows build). I believe that Python should be the language of choice, if a language had to be picked, for a number of reasons.

This is more of a cross-platform request, I understand why it would be attractive to implement AppleScript on the Mac version although I think it would be better to implement a scripting language that is common to every system Scrivener runs on.

I have read that you plan to add AppleScript support which is great, but this creates issues for users of Scrivener on Windows and Linux: AppleScript is not supported in Windows or Linux. Granted I realise that each build is different but using one scripting system across each platform will make porting scripts much, much easier.

Which leads into my second point: Python is cross-platform compatible (and I believe is included on OS X and many Linux distros by default), so code can be ported to other platforms with little or no modification. Python can be quickly and easily downloaded and installed for Windows (if not distributed with Scrivener). This would make Scrivener scripts highly portable, and be a very attractive feature of Scrivener for developers: only needing to write a script once and target multiple platforms with ease.
That said, some minor modifications to some scripts may be required if OS specific functions are called. This can be easily worked around: by making the script aware of each OS, adapting to the environment (a decision that would be ultimately up to the developer).

It seems by implementing AppleScript on the Mac version, and then to implement a different scripting system other versions (assuming the Windows and Linux builds will include scripting support in future) is creating additional work to maintain each build of Scrivener, at least in my view. This would also heavily restrict scripts from being interchanged between each build since at least two different languages would need to be used seeing that AppleScript isn’t supported in Windows or Linux (that I can see), presuming that Windows and Linux use the same scripting language.

Another issue that you may run into is that AppleScript cannot be ported to Windows or Linux because the EULA it is licensed under may not allow it. Python doesn’t have this restriction and is already available on OS X, Windows and *nix. Python isn’t included with Windows by default but can be easily downloaded and installed (if not distributed with Scrivener).

A few other issues come to mind: it seems that Python has a much larger user base (owing to its cross platform nature), is open source, and is also very easy to pick up owing to it’s easy to understand syntax and ‘pythonic’ principles. Scrivener can also be extended using other libraries using Python and is well documented officially. There are many books on Python programming too, making it a very attractive language.

Please don’t take this as an attack on Scrivener, I think Scrivener is a -ing excellent package and am seriously considering that it take over my academic writing from Microsoft Word, as I am currently using it for NaNoWriMo 2011 and am very impressed with its layout and feature set.

Unfortunately the only thing preventing me is lack of EndNote support (referencing package I use, created by Thompson Reuters) but which I could work around with scripting. Given that EndNote is also available on the Mac, I wouldn’t need to completely rewrite my [Python] script in AppleScript to benefit Mac users of Scrivener, not to mention supporting two scripts in different languages. As a programmer myself (currently hobby, admittedly but am undertaking a Bachelor of Information Technology to work in Software Design and Development) I try and keep my code in one language which what makes Python so attractive: write once, deploy multiple, modify as necessary.

I am very keen on extending Scrivener to be much more academic and blog friendly as well. As soon as (hopefully cross-plaform) scripting is added: Scrivener would be come a “shut-up-and-take-my-money!!!” type application for me. :laughing: I’m concerned that adding AppleScript will leave Windows and Linux Scrivener users out in the cold, and make porting scripts difficult.

Thank you for taking the time to read my response, I appreciate any feedback you have.

Cheers!

df.

+1

I agree with deltafalcon.

The idea for L&L, from a business standpoint, I think, is to develop what is sometimes called a “third-party-support ecosystem.” Having third-party developers writing code to enhance your product and not having to pay them is a great idea. Some do it so they can have functionality they need. Some do it to make a little (very little) money.

Developing such an ecosystem starts by implementing a plugin API that can be used by any developer on any of your supported OSes and that will run with little or no modification on the other platforms. Plugins could be free open-source software or closed-source for a fee. It doesn’t matter. When a plugin’s availability is posted, it states the OSes upon which it has been tested. If other developers or users want to test the plugin on their OS, they are encouraged to try. If it doesn’t run, patches to make it run are accepted if the code is open-source.

If anyone has used Gedit (http://projects.gnome.org/gedit/), that’s the model. Gedit is a small text editor that uses Python as its extension language. It runs on Linux, OSX, and Windows. Most of its advanced features come from Python plugins written by people other than the core developers.

What matters is that plugins are developed once and unless OS-specific or Scrivener-version-specific features are used, can usually run on all supported OSes (oh yeah, Linux) without reimplementation. That’s the benefit. For L&L. And for all of us.

My opinion? Don’t do Applescript. It only benefits Apple users. Don’t do COM. It only benefits Windows users. Python benefits all of us.

(And there might even be some enterprising developers who would do the work of designing and implementing the plugin API pro bono just so they could write cool tools for Scrivener.)

A minor point – Applescript is as much a platform integration tool as it is a scripting language. Many uses of Applescript allow uniformly rich interactivity across applications (services and automator in OS X as prime examples of uniformity across the OS). This does not necessarily interfere with an in-app scripting environment. The two can happily co-exist :wink:

As an OS X user, I would still strongly support the use of a cross-platform solution like Python for an extension API. Python has been used in many products in this way, and though I personally prefer Ruby syntax, suspect cross-platform more coders likely to write extensions know Python…

Sublime Text 2 is another example of a text editor using a Python API for extensibility:

sublimetext.com/2