AppleScript: what do you want to see in the Scrivener Suite?

[xiamenese]

I think if I could import attachments directly from Mail into Scrivener, that would be a reason to switch back from GyazMail to Apple Mail ... unless of course it was possible to set up an Applescript that worked with GyazMail.



Mark

[howarth]

I work with Entourage, but that process is fairly simple: (1) select the attachment and drag to Desktop, (2) select the file and drag to Scrivener. A script might make that quicker, but how would it know where to place the file? I guess I'm wary of automation that cuts into thought and decision.

[KB]

Hi,

Sorry, maybe I wasn't very clear in my original post - I guess if you have never written an Apple Script then the first post didn't make my question very clear.

I don't want any suggestions for actual Apple Scripts here. Things like an import for MMS or Final Draft, or a direct Mail attachment import and suchlike could possibly be supported via Apple Script, but that is not my concern at all - that sort of thing will fall to users who want to create Apple Scripts for Scrivener. I won't be creating any myself (I am not an Apple Scripter as already mentioned).

No, I am really asking the people who use Apple Script what sort of commands, elements and suchlike they would like to have access to in order to create such extra functionality.

To reiterate, I would like ideas for the contents of the Apple Script dictionary itself, and not suggestions for actual Apple Scripts that could add functionality to Scrivener, as that is up to others.

Thanks!
Keith

[miles111]

I am really asking the people who use Apple Script what sort of commands, elements and suchlike they would like to have access to in order to create such extra functionality.

One of the fastest ways to add automation functions to Scrivener might be to add some Automator actions. I use Automator to to move email messages into a FileMaker database, for instance. I also use it to move any desired selected text from a webpage into the appropriate FM database. In all, I probably use about a dozen Automator scripts. Some Automator actions work on their own, while others complete specified steps, then trigger Applescripts created by using FileMaker's built-in Applescript creation tool: ScriptMaker.

With FileMaker the user can open ScriptMaker and select "steps" from the large menu of commands offered. The script then runs through each of the selected steps until the entire script has been run. This makes it fairly fast and easy to use. If a user knows how to write his own Applesctipts, they can be added to the ScriptMaker script where they will then run as an additional step within the FM script.

—m.

[KB]

Yes, but the point is that in order for an app to work with Automator, it first needs to be AppleScriptable - I most certainly will not be providing any Automator actions, that will be left to users for now. Which brings me back to the original question: what sort of AppleScript commands and elements should be available? I sort of feel as though I am talking in circles here.

So, to keep this on-topic: please post only suggestions for what should go into a Scrivener AppleScript Suite. If you do not know what an AppleScript Suite is, please do not post in this thread (but feel free to post any such suggestions elsewhere on the forum, of course). The main reason I ask this is not to be rude, but because I don't really understand AppleScript myself, so I'm kind of asking for help here. Browsing through the documentation I can find, it is starting to look a lot more complicated than I had anticipated, and this may well get left until 1.5 or 2.0 now.

If you do understand AppleScript, please do post ideas for the Suite, and any advice you can give me on getting to grips with this would be much appreciated.

Thanks!
Keith

[jeremydouglass]

Don't lose heart. The ability to *create* entries at the bottom of the binder with defined terms for *title* and *contents* (optionally, *abstract*) would be a great first step - metadata options can wait, and import is probably more important to most people than export, so you could also just put export off until later.

I don't know enough about the inner workings of Scrivener to understand how you would support non-textual importing, but I'm assuming you would use a create/import which accepts either a POSIX *path* or *URL* in order to import images, pdfs, webarchives, weblocs etc.

My extremely unscientific guess is that creating title/contents and importing POSIX paths or URLs is 90% of your use cases - some people (like me) will also be extremely excited about preserving particular metadata (mailtags-keywords, file datestamps, labels etc.) or about exporting, but that is probably your last 10%, and can wait.

[Khadrelt]

I'm not entirely clear on what an application has to include in its suite as opposed to things (if any) that are just part of OS X, but here are a few thoughts:

selected text
selected binder document
convert (binder document into folder)
insert (as in inserting a file on your computer into the Binder)
create (create a new blank document in the Binder)
merge (merge two documents in the Binder)
split (split a document into two at the insertion point)
move to trash
empty trash

Also have a window class (id, position, bounds, etc).

[edf]

Just noticed this thread, and yes I have some ideas :)

To get a general feel what an Applescript Suite should support, run the Script Editor and open the dictionary for DevonThink. You'll notice two types of exports: data types (i.e. objects with properties) and actions (routines called to get objects or interact with the app).

If I were adding Applescript for Scrivener, I'd add at least the following data types:

Application (has Active Wndow contains DocumentWindow, Current Project, Recent Projects, etc)
DocumentWindow (has Selected Text and such)
Project (has name, notes, contains Binder)
Binder (contains BinderItems, has Root Group which contains Drafts/Trash/etc)
BinderItem (has name, path, synopsis, notes, references, type, label, status, keywords, etc)

..and so forth.

I'd support the following actions like the following:

open project (closes current project)
create binder item at path
delete (to trash) binder item at path
move binder item at path to path
get binder item at path
take snapshot
backup project to file_path
export project to file_path
import file at file_path to path

Applescript is used for two things: automation and interacting with other applications (could be considered the same thing actually).

This means that there needs to be direct access to the raw data in Scrivener (text, keywords, labels, status, references, and notes) via data types, and access to commonly-automated tasks (opening, saving, exporting, importing) via actions.

In an application like Scrivener, exposing the data types (which are all native to OS X and will play well with Applescript) is more important that providing routines. Consider the likely use cases, and how the scripts for them would be written:

* List unfinished items: iterate over documents, printing all with TODO status. Same applies for listing document keywords, references, etc.
* Add metadata to a document: find document, modify notes/ref/keyword/status/synopsis
* Apply text changes: find document, modify RTF directly
* Add file to project: invoke import routine
* Export data from project: compile export settings and list of object IDs to export, then invoke export routine
* Send selected text to application : get selected text, tell application

I don't see much value in adding applescript support for the kind of stuff that generally requires human interaction/judgement, e.g. merging and splitting documents/empty trash, or for the stuff that applescripts can easily do themselves, e.g. convert case/insert date/etc.

So the heart of the applescript suite would be the BinderItem data type:

BinderItem
Name (string)
Location (string: path from Binder root)
Path (string: path inside project dir)
Type (r/o)
Title (string)
Label (integer)
Status (integer)
Synopsis (string)
Create Date (r/o)
Mod Date (r/o)
Include in Export (boolean)
Page Break Before (boolean)
Preserve Formatting (boolean)
Notes (string)
Keywords (list of Keyword objects)
References (list of Reference objects)
Target (?)
Progress (?)
Children (list of BinderItem objects)

Note word count and char count are unneccessary for BinderItem as they are inherent properties of applescript strings, though per-project counts should be included.

Based on this, the rest of the data types become obvious (Reference, Keyword, Binder containing BinderItems, Window containing Binder, Application containing Window), and the routines simply become ways to either to access (create/find/delete) the types, or to perform operations that aren't related to modifying data stored in types.

[KB]

Thanks edf - they are great ideas and that looks like a very good start for an AppleScript suite. Shame that implementing the Cocoa side of it looks a lot more difficult (and obliquely documented) than I had hoped...

[edf]

You mean it's not as simple as setting NSAppleScriptEnabled to True in the plist? ;)

Yeah, scoping out the Cocoa Scripting Guide doc, it looks a bit involved, and the writing is rather obtuse. Reads like agile programming books.

This guy has a decent (but possibly outdated) play-by-play of adding applescript to an app, if it helps:

http://www.stone.com/The_Cocoa_Files/Adding_Applescript.html

Some complaints and workarounds are given here:

http://earthlingsoft.net/ssp/blog/2004/07/cocoa_and_applescript

All this Cocoa discussion makes me glad I'm off doing backend stuff these days.

Good luck! I'm looking forward to scripting Scrivener

[albertsen]

I'm not an AppleScripter, either. Like a lot of "serious" software developers I'm put off by the language syntax. But I think it's worth learning it, and if you add AppleScript support to Scrivener that's even more reason for me to learn AppleScript.

I would mainly use it to automate export (especially in Markdown format). I write my short stories in Scrivener and it would be great to have a script to automatically publish them to me website. For this I would need to AppleScript access to the whole export process.

Apart from that, access to all binder elements would be great, too, especially, to be able to create new folders and chapters.

BTW, if you don't like the AppleScript syntax have a look at AppScript. It provides access to AppleScript suites in Python, Ruby and even Objective-C: http://appscript.sourceforge.net/

Jürgen

[edf]

Applescript truly is a horrible language -- it's been called the only read-only programming language (in the sense that Perl is a write-only language). The core concepts, though -- the 'tell' blocks that send messages to receivers defined in applications or linked-in standard libraries -- work great as glue in a GUI environment. Quite possibly the best GUI analogue to UNIX shell pipes.

Appscript is a nice improvement, with one fatal flaw: it doesn't ship with OS X (well two flaws: the versions of python and ruby that ship with OS X are ancient enough to be all but useless). If you plan to distribute your scripts, even just to less-technical friends, you will face install issues.

Personally, I've gotten a lot of mileage out of osascript and 'do shell script', though I'm sure I reimplement a fair portion of appscript in the process :)

[albertsen]

First of all, the versions of Python and Ruby are not that ancient (well, that depends on how you define "ancient"). They were the state of the art when Tiger was released more then a year ago. I think the Ruby version shipping with Tiger is 1.8.2, and the most current is 1.8.6.

Apple is very open to integrating open source components. Leopard will ship with RubyCocoa, for example, fully integrated in XCode (and also with Rails, btw). So I don't see that we won't see AppScript integrated, perhaps even as soon as with the release of Leopard.

Jürgen

[KB]

Thanks all for feedback. AppleScript is now unlikely to make it into anything like 1.1 and probably will, after all, be held back until 1.5 or 2.0. Further investigation has revealed just how much work this would be - too much for the time being, unfortunately. Still, I will keep this thread open and use it for reference when the time comes.

Oh, and you are all banned from mentioning Leopard. Apple's refusal to make the WWDC beta available to paying ADC members (despite the fact that pirates can already download it as a torrent) makes me so mad that I can't actually name the spotted cat without spitting venom.

Best,
Keith

[Khadrelt]

Now, I just don't get that. Assuming, as I do, that just about every corporation out there is bent on one thing and one thing only - making money - this whole thing still just doesn't make sense. Withholding that beta from developers isn't going to make Appleany money, not that I can see, and it wouldn't hurt them at all to make it available. I'm just not seeing the reasoning behind the whole thing. If there's no benefit to them, why is it happening? Doing such a thing on purpose will only make people mad. Is there more to this that I'm not understanding here?