One button compile draft

Scrivener
,
1

I’m producing my thesis in Scrivener+MMD and often need to proof what it’s gonna look like when I change some sections, add headers, graphs, etc. I know Scrivener is for slowly writing your next Tolstoyevsky novel and then exporting it for typesetting in another app; but still I’d like to cook up some very efficient way to enable one button proofing with MMD. Since this is not specific to MMD, and the crux of the matter is where the process starts – in a Scrivener menu – I’ll start it here, in addition to the MMD question which is still alone in its MMD thread…

So basically what I want is: compile the document with all the previous settings and overwrite any previous compilation outputs. Single keystroke, silent work. Possibly open up a PDF viewer – but since I use Preview, and it updates the PDF by itself whenever it changes, no need to do enforce view update.

When inspecting Scrivener in AppleScript Editor, it’s immediately clear that it supports almost nothing – apparently the windowing and RTF dictionaries are inherited from Apple. I’m a newbie to AppleScript, but am a pretty good programmer, so I “only” need to pick up some AS hacks… But this is nothing to work with.

So I remember I’ve seen some excellent software by Bill Cheesman, now across the river from me, and Google for it. Here it is:

pfiddlesoft.com/uiactions/
pfiddlesoft.com/uibrowser/

I’m thinking of attaching an action to “Compile Draft…” menu, which will fill in a given file name – alas hardcoded I’m afraid – and then hit replace, if any, and run. In fact, I remove the output folder manually now before compiling, since this saves the replace dialogue, so I might remove it just in case before providing the file name.

Any thoughts/hints/examples? Perhaps the author will add the one button compilation – unless it’s already coming in 2.0? :slight_smile:

2

OK the silence is deafening. Is it the silence of the lambs, or before a coming storm?

3

Braver,
This is Tech Support forum.
Try posting it in the wish list forum. :wink:
vic.

4

This is not just a wish, this is a strong belief that we have a bug. :slight_smile: As any powerful and self-evident belief, it will, by sheer force, right itself. Every scrivener has a right to writing, freedom to reorganize, and one-button export.

5

I’d slightly disagree with your assessment. A bug is when an pathway doesn’t work as intended, and in this case the pathway works precisely as intended. Your proposal really is about adding new features to the pathway.

Here is how things will work in 2.0 that are a little different: When you compile over an existing document (or generated folder for MMD with media), the contents will be overwritten in place instead of creating new copies. So if you have TextMate open to the tex file you just compiled, and see something you want to tweak in Scrivener, you can compile again (Cmd-Opt-E;EnterEnter;Cmd-R will one-shot this out and can be done “blind”; you don’t have to wait for all of the dialogue boxes to show up). Progress bar completes—switch over to TextMate and changes are loaded. It’s pretty darn fast. So the main change here is that your chosen name is always supplied by default, meaning you don’t have to even look at the any of the compile dialogue boxes—and folder style compilations will overwrite the contents of the folder in place, rather than creating a serial numbered folder. From TextMate you can Cmd-R render the LaTeX file, and if the PDF is already opened in Preview or Skim, it should pop up shortly after that.

As for making PDFs, that’s more complicated because it almost always requires a some running and re-running and maybe even index and glossary updating. Excepting the last two, it’s pretty easy to make a script that will run LaTeX two or three times and spit out a PDF. In fact, I think recent distributions of MMD have a script already built for this. You could try symlinking the LaTeX script that Scrivener uses during compile to this script instead of the standard script. I’m not sure if that will work though. Do be aware that this will dramatically increase your post-compile wait time—that period of time after the progress bar finishes, where Scrivener brings up the “unknown interval” style progress bar and holds until the MMD processes complete.

It’s not one button, but I do this constantly and it works fine for me. I can go from Scrivener to viewing the PDF pretty quickly (depending on the document size), and with only a few keystrokes.

6

Ioa – thanks for the preview of the 2.0 export pipeline! I’m not concerned about latex after it comes out of MMD, I got shell scripts and everything else, e.g. Hazel for it. What I’m really striving for is, let my latex out of Scrivener at once when I say so! Opt-Cmd-E;EnterEnter is not a single button! How do you do it – just type? At least we need some automation here to make it really a single button, IM[Strong]HO. I have a meeting with the great Bill Cheeseman, of the Vermont Mac Recipes and UI Actions fame, set to explore how we can attach some actions to Scrivener as it stands now. BUT, it really should be like LyX’s Cmd-T. E.g., in LyX, if you have any complex conversions, such as running R code through Sweave, Cmd-T there runs R, produces histograms, and absorbs their PDF outputs into the final overall PDF – that’s the example of a single export keystroke which produces everything, and I think “Compile Draft…” raises expectations of one keystroke compilation, at least among us geeks.

Given 2.0 doesn’t need retyping of the file name, perhaps some keystroke macro solution might work – ideas, anybody?

7

Regarding AppleScript, the currently available stuff is just a stub. Implementing AppleScript properly is a big job. I had wanted to include it for 2.0, but it’s got pushed back, and is currently slated as the main priority for 2.1 (but of course there’s no ETA on that other than next year sometime).
All the best,
Keith

P.S. You beat me to it. I disagree about one-click Compile Draft, by the way - it’s not really standard anywhere. Compile Draft is an export or print feature, and throughout OS X both export and print are not one-click things. And certainly nothing else is getting added to 2.0 at this late stage, so close to release. :slight_smile:

8

Precisely. Those are the keyboard commands you use to compile something over something else (The Cmd-R at the end selects the Replace button). I don’t even think about the sequence any longer, that sequence of typed in keys just rolls off my fingers and a bit later I have an updated .tex file.

It’s not one button but honestly it’s pretty close. Like I said you don’t have to wait for the application, keys typed in before windows come up are buffered in the system and enacted on the resulting displays as they appear. Most of the displays are just a flicker when I rattle this off. The vast majority of the CPU time is spent on the processing itself, which can be considerable with a large work. Reducing the front-end user load from .28 seconds to .15 isn’t going to make a big difference when it takes 1–3minutes to fully compile and process several PDF runs.

Actually I do kind of disagree with this because a PDF from Scrivener is several steps removed from even LyX. There is a lot of processing and user interface in between those two points! Tens of thousands of lines of code, executing from nearly half a dozen different applications, and a multitude of failure points at every junction. It takes a huge amount of processing just to get to a .tex file, which is where LyX is roughly starting from. I do agree it feels the same though.

All that said, as Keith put, AppleScript is on the slate, and I suspect you’ll at least get the first part of this, the compile initiation and post-processing part anyway, into a script once given the tools to do so. Combined with the suggestion to try out MMD’s PDF script, you could probably get the whole thing done with one script. It probably won’t save you much if any literal time, but it might feel that way. :wink:

9

Using Bill Cheeseman’s excellent Ui Browser, http://pfiddlesoft.com/uibrowser, I’ve been able to find out the GUI elements in any Scrivener menu and script it easily. Here’s a solution which uses a script, called “Scrivener Export”, in the script menu on the tooolbar; choosing it makes Scrivener repeat the last export and open the resulting document. I’m using MMD=>LaTeX export, but you can easily adapt the idea to any output format.

Some points about my setup: I use a directory /l to place symlinks to various working directories. My thesis is in ~/Documents/Thesis, symlinked to /l/t. I use the make utility to produce the PDF from LaTeX, with the following Makefile:

PATH=/usr/texbin:/bin
f=t
d=$f.tex
t=$f.tex
pdf=$d/$f.pdf

all: pdf
	open $(pdf)

1:
	(cd $d; xelatex $t)

pdf:
	while [[ ! -f $d/$t ]]; do sleep 1; done
	(cd $d; xelatex $t; bibtex $t; xelatex $t; xelatex $t)

.PHONY: t o d
t:
	rm -fr $d

o:
	open $(pdf)

d:
	cp -p $(pdf) ~/Dropbox/Public

Now for the AppleScript itself, called Scrivener Export:

do shell script "cd /l/t; make t"
activate application "Scrivener"
tell application "System Events"
	tell process "Scrivener"
		-- insert GUI Scripting statements here
		click menu item "Compile..." of menu 1 of menu bar item "File" of menu bar 1
		click button 1 of sheet 1 of window 1
		set value of text field 1 of window 1 to "t"
		click button "Export" of window "Export"
		-- click button 4 of window 1
	end tell
end tell
do shell script "cd /l/t; make"

I remove the previous version before exporting a new one, which avoids any “Replace?” dialogues. You have to have GUI scripting turned on, which is done by checking the box “Enable access for assistive devices” in the Universal Access panel of System Preferences.

Interesting observation: until I put the waiting loop in place, which makes sure that the .tex export file exists before latexing it, I was getting an error that there’s no such directory; it means Scrivener returned control to the AppleScript before the export was done, i.e. MMD running in a separate thread or something like that.

Finally I can start the export with one click, sit back, and watch a PDF update in Preview!

BTW, Bill said that the original “Compile Draft…” dialogue violated Apple UI guidelines, presenting a sheet on top of a sheet. Apparently we have a window on top of a sheet now (don’t know whether that makes it better or not :slight_smile:).

10

Yes, that’s standard (but presumably you’ve never tried to print on OS X, or create a new folder from a save sheet :slight_smile: ). And believe it or not - shock, horror! - I’m very familiar with the Apple HIG - to the extent that I recognise how much Apple violates them by placing the View menu next to the Window in Pages etc too (so I hope you have been writing “my friend Bill says…” missives to the iWork team, too, or else I shall be most put out).

All the best,
Keith

BTW I have a lot of respect for Bill Cheeseman (I have his programming book), but fortunately there are some Cupertino guys who have given me some great feedback on Scriv’s interface, so I hope I’m doing something right somewhere. Mr Cheeseman has been doing this longer than me so I bow to his superior knowledge, but I do question your reasons for posting such comments here in a thread where you are trying to force a point. Thanks for your comments though. :slight_smile:

11

Keith – I’ve admittedly boasted a nugget of second-hand UI knowledge, merely as a memento of being lucky both to meet Bill and own Scriv, in no way to kick the latter! :slight_smile: I’m perfectly happy to use my GUI kludge until Scriv gets AppleScript, or instead of it, so no need to force a point, all is good. I probably should have started with congratulating you for making Scriv, soo cool to begin with, even cooler looking; hope being a scientist in need to record everything seemingly relevant or potentially useful may excuse my paux pas! :slight_smile: Cheers.

BTW, this script applies only to Scriv 2.0 (into which I paid-upgraded at once, voting with my hard-earned bucks and downloading over 3G [even more hard-earned bucks!] to GoodReader on iPad to transfer to the Mac in my neck of the woods! See, I string all the nuggets along) – if anybody needs the original, serving Scriv 1.0, it’s here:

activate application "Scrivener"
tell application "System Events"
        tell process "Scrivener"
                -- insert GUI Scripting statements here
                click menu item "Compile Draft..." of menu 1 of menu bar item "File" of menu bar 1
                click button 1 of sheet 1 of window 1
                set value of text field 1 of sheet 1 of sheet 1 of window 1 to "t.tex"
                click button 1 of sheet 1 of sheet 1 of window 1
        end tell
end tell
12

Ah, you just touched a nerve, because I like Bill (from his posts to the Cocoa lists, and his book) and respect his opinion, so it stings to know he criticised Scriv. I changed the sheet to be a panel in the new Compile sheet especially to better conform to the UI standards, but there are still a couple of places where there are sheets-within-sheets that would no doubt receive censure from the purist (cf. the “Options” and “Title Options” in the “Formatting” pane of the Compile sheet). I thought long and hard about them, but really a modal panel wouldn’t be functionally different even if more “by-the-book” correct, and it just felt worse in practice.

AppleScript will be coming to Scriv - eventually! - too, and your comments about one-click Compile have been noted. It’s not that I think it’s a bad idea, but I’m not sure where it would fit without being a confusing second menu item. It’s the sort of thing that would work nicely as an alternative menu item (replacing the existing item by holding the Option key down), except that Compile already uses the Option key in its shortcut.

Just living up to my reputation for "gruff"ness, but hey it is after 2am and I have a belly-full of beer - I should be banned from posting at such times. :slight_smile: Thanks for your good humour in response, appreciated.

Thanks and all the best,
Keith

13

I added a Scriv 1.0 version of the AppleScript above. To me, the ease of GUI scripting any OSX app was revelatory; embedded ApplieScript or now, this is amazing, and Bill’s UI Browser makes it a breeze to find exactly which UI elements are needed. For me it’s one of the first forays into Cocoa, and I’m impressed. Hopefully these techniques can be useful to folks.

14

Yeah, the sheet within a sheet thing is a little strange, but frankly there really is no good alternative. The alternatives are: overly complicating the base interface with tons of peripheral/secondary/advanced options, or floating modal windows. Both of those are quite unsatisfactory.

In my opinion the HIGs are good for 95 out of a 100 cases, but nearly every program is going to have a few within those remaining five, and some programs are going to have more. Can you imagine how awful Photoshop would be if it rigorously held to the entire HIG? Exceptions are all right, if the exception is used to deflect a less satisfactory outcome.

15

I have to take up the challenge/comment from Keith in another thread, that no thread on these fora can go more than a certain distance without diverting to linguistics … but hey, we are all very much focussed on words, are we not.
What is a “guideline”? If something is a guideline, is it a regulation writ on tablets of stone? Or is it a pointer to good practice? I take it as the latter, so I’m behind Keith and Ioa; if breaching the HIG in a particular instance, in a comparatively minor way, results in a better user-experience than following the HIG would, then the breach is appropriate.
Of course, if this is something that would be a problem in getting Scrivener OK’d for the App Store …
:slight_smile:

Mark

16

It’s about time we got some linguistics into this discussion, thanks Mark. :slight_smile: