[KevinH]

Hi Varlog,

Not quite understanding this new architecture yet but:

The general idea is to register a script and it interpreter path as you have done along with a type attribute.

When a user launches the script, a Modal Dialog Pops up with infinite progress widget and a cancel button, and it gets passed all of the info needed for the script when it invokes ScriptInterface.

ScriptInterface invokes QProcess so that it exists as an object even though the method code that started it has closed. This QProcess will be passed a specific set of arguments depending on its registered type:

For an editor type it will be passed:
- path to the root of the book (read only)
- path to the opf of the book (read only)
- path to a temporary directory where all results will reside

The wrapper python code (or any code for that matter) will read these values, copy into the output space any files it needs to modify, and proceed to modify those files.

Depending on the wrapper language, the wrapper can add xml parsing, xpaths, spine decoding, opf parsing (to get back a list of id by mimetype for example). The wrapper can also use its own gui widgets at this point to ask for paths, user input, etc.

Then the wrapper script will import the actual target script and run it collecting the output and any error messages.

Once the target script has returned, the wrapper script will build a simple xml file that it will print to stdout before exiting. It would look something like the following in its simplest form (this is just off the top of my head, we can adjust this as we see fit)

<wrapper charset="utf-8">
    <result>success</result>
    <deleted>
        <manifestid>id</manifestid>
        <manifestid>id</manifestid>
        <manifestid>id</manifestid>
        <manifestid>id</manifestid>
    </deleted>
    <modified>
        <manifestid>id</manifestid>
        <manifestid>id</manifestid>
        <manifestid>id</manifestid>
        <manifestid>id</manifestid>
    </modified>
    <new>
        <file href="url" mimetype="newfilemimetype" uniqueid="id" />
        <file href="url" mimetype="newfilemimetype" uniqueid="id" />
        <file href="url" mimetype="newfilemimetype" uniqueid="id" />
        <file href="url" mimetype="newfilemimetype" uniqueid="id" />
    </new> 
    <errorlog>
          "escaped text from target script stderr output only if failed"
    </errorlog>
    <successmsg>
          "escaped text from target script stdout output only if success"
    </successmsg>
</wrapper>

For an input script, we would only pass in the temporary output folder and then its wrapper would basically pass back xml that represents all of the new files (or simply a path to the new root and new opf),

For an output script, we would pass in the read-only path to the root of the book and path to its opf file.

The output wrapper would return a a similar xml success script along with a successmsg of where the user can find the file.

The ScriptInterface code would then grab the wrapper result xml and use it to perform all of the required manipulation inside Sigil to accomplish what needs to be done, show either the error message or success message and wait for the user to click <done> ending the model dialog.

The key idea is that I can write the python "wrapper" codes for all of these types that users can simply use to copy and paste in importing their own "target" code and getting it all to work. We can also develop wrappers for other crossplatform scripting languages such as perl , Lua, Javascript, etc.

I can add new attribute "type" to script manifest with appropriate values:

 
<attribute name="type" use="required">
    <simpleType>
      <restriction base="string">
       <enumeration value="input" />
       <enumeration value="output" />
       <enumeration value="edit" />
       <enumeration value="meta" />
       <enumeration value="other" />
      </restriction>
     </simpleType>
  </attribute>

and remember it in Settings and elsewhere, so that ScriptInterface class (or other classes?) could react to this. This will make my sigilResource tag redundant. Do you propose to remove it? The whole architecture depends on it at the moment.

See the above which should hopefully make the idea more understandable.

Just in case I added "other".

Please don't. I have no idea what a wrapper class would be for other and how it would interface. We can always include other concrete script types in the future when and if we need more script types.

Ok, I'll look into it... just be easy on me, I'm newbie...

No worries! Once you see how the interface wrapper works, all of this should make more sense. Just remember, we will not be just integrating in any old script, instead script writers will use our premade wrappers scripts to add their code to it to create a proper script plugin.

I can create one for KindleUnpack, so that Sigil will gain full mobi support, one to invoke kindlegen to allow for Mobi output support, scripts to strip koboisms, scripts to create nav (like yours), scripts to add convert current meta data to epub 3 versions, etc.

We can also actually add public methods to the friended classes so that we no longer need the friend stuff nor the pre C++11 switch either.

Hope this all sounds good to you. If not, let me know.

Thanks,

KevinH