As a backgrounder I have seen a very useful feature in Sigil – which, in my opinion, is one of its most simple, endearing and powerful features – whereby you can right click on a chapter section in the Book Browser then select an outside application like Dreamweaver or HTML-Kit to work on the HTML. And once you’ve worked on the html in, say, DreamWeaver then you save these changes back to the applicable html section or chapter in Sigil.
The above suggestion would also completely have to assume that the Scrivener writing environment is basically HTML. Using the above design principle – Calling in and using outside apps in this way would also perhaps achieve several important things:
-
More choice for the Scrivener user.
-
It would also reduce and help avoid the designer’s nightmare of adding more and more bloated code into Scrivener while, at the same time, increasing Scrivener’s capability and satisfying user needs at relatively low code and design costs.
-
You could add in other outside apps in this way – such as for html, citation/reference apps or image apps(user’s choice) that could still do the job from within Scrivener. This added outside functionality, I think, would not offend Scrivener’s own unique philosophy, project environment or capabilities. It would also help to keep Scrivener sleek and fast.
There are several other apps that use outside apps as well as plugins for added functionality. Both Notepad++ and Sigil are notable examples of well-loved apps that have successfully used this design philosophy.
The thing with Scrivener is — which you should be even more aware of as a Windows user — that a project is a combination of potentially thousands of files on disk, and that even a small edit to one of them means changes to the support files. So, if you edit the individual documents in another app, those changes won’t be made to the requisite support files, with the worst case scenario being a totally screwed up project. There are lots of posts on the forum with people appealing for help as their project will no longer open, usually down to conflicted files or more than one .scrivx file in the project.
The Mac version has a “folder sync” system which allows files to be exported, worked on in another app, for instance on an iPad, and then sync’d back to the main project. I don’t think that has come to Windows yet, though it will do at some point.
And of course, Scrivener’s native format is not HTML but RTF, and I guess the guys have enough on their plates without having to redo the whole thing to use HTML instead.
Mr X
Hi X…I’m not sure that you fully understood my post. I was talking about calling independent outside apps that could be called and used from within Scrivener. So there would be no interference with Scrivener code in this respect – because you’re calling an independent outside application using a completely different memory space. I’m afraid I don’t understand your reasons about “thousands of files on disk” and I think you’re completely missing the point with your statement here:
"So, if you edit the individual documents in another app, those changes won't be made to the requisite support files, with the worst case scenario being a totally screwed up project"
If you save the changes to one file via the outside app then you just save it back to the same chapter or section in Scrivener through a thin and simple Save interface. How difficult is that to code? And if small and popular apps like Sigil or Notepad++ can use this as a successful design philosophy then why not for Scrivener?
And I’m not just talking about calling outside apps for rendering just html or rtf files. I’m talking about calling in outside apps(user’s choice) for working with image apps and citation apps or referencing apps etc. Doing it the way I’ve suggested – calling an outside app – saves the Scrivener programmer(s) having to re-invent the wheel with reams of code every time they have to do a major functional update.
Another possible enhancement, which would both benefit Scrivener and perhaps reduce the Scrivener programmers load would be to build a plugin interface(using python or ruby or perl?) for Scrivener to allow outside developers to develop useful plugins. These plugins would create even more capability and interest for Scrivener and would indeed be added reasons for buying Scrivener. Initially, building the plugin interface for developers to use would be a large task. But once complete and thereafter, outside developers could perhaps run with it on their own and develop plugins which could be used for free – this must also act to naturally enhance Scriveners reputation with no extra load or cost on in-house Scrivener development. And as long as Scrivener was willing to test and control the quality and recommend these plugins, this would also be quite a low-cost way of perpetually and naturally enhancing and assuring Scrivener’s capabilities, reputation and competitiveness for the future.