Hi varlog,
Quote:
Originally Posted by varlog
Kevin,
please reconsider. There are scripts (AppleXML for instance) which don't need anything.
My idea is:
Sigil generates legitimate path to tmp and passes it to script,
script creates (or not) tmp according to path, does its thing and exits,
Sigil checks if tmp exists, does its things, deletes tmp and goes on.
Unnecessary disc activities (hate them!) avoided  .
Or do I miss something? As all belongs to Sigil premissions should be ok?
ps: bugs, bugs and bugs again... f... |
I simply do not understand. The temp directory will automatically be created if you use the TempFolder class the way it was meant to be used and automatically removed upon completion by its own thread. You need do nothing extra. Loading any script and running it will generate *much* more disk activity than creating a temp directory and removing it.
You seem to be missing the point that under the proposed script interface that NO WRITES are allowed in the ebook root path, ... only reads and only when needed. All modifications/writes go to the temp (output) directory. So there must be a temporary directory to store ANY files modified, added or deleted.
Yes, if nothing is ever modified or added, or deleted, then we have needlessly created an empty directory and removed it automatically. I am not too worried by that possibility.
Please remember, we are trying to implement a different system from the one you proposed. So we are not using your SigilAction code anymore, nor do we need to select all text resources just to modify text files, and we don't want anyone other than Sigil to write to the ebook root path for any reason (to prevent Sigil from having to use/parse non-valid xhtml, invalid opf changes, etc).
That was the whole point of the container classes and wrapper.py and the use of xml to return much more information about the proposed changes, and to keep the opf properly updated and safe on the fly. The python scripts provide all of the iterator()s to easily access read, and modify any class of resource. Please see how easy it was to support the NewUUID and Smarten scripts by only adding a small routine to act as an interface between what the container class provides and what the target script needs.
So please let's just focus on getting something going from the register / launch side of Sigil with a proper modal dialog with show(), and proper use of QProcess so that we are not blocking any gui events.
Worrying about who creates a directory just to save possibly uncreating it, makes no sense to me at this point. I want to spend what little free time I have actually generating code. We can always change things as we go along (the very heart of rapid prototyping) but we need something to get going first.
Hopefully, you can live with that, if not just let me know.
Take care,
KevinH