Sigil script manager

[KevinH]

No,
for all 3 script types, Sigil passes in real ebook path, path to temp directory Sigil owns, script type, and path to target script. the real ebook path is only ever read from. All writes go to temp directory which Sigil uses to validate from and update it's own files upon return of launcher.

when Sigil only wants to pass in selected resources and not full book, it creates a temp directory to act as ebook root and fills it with just the selected resource and then passes that as ebook root.

Sigil must own and create/destroy output temp directory so it exists after the launcher process ends.

The launcher copies on write to output directory and has all the iterators to access any class of resource easily, so no need to send long lists of text XHTML files.

Hope this explains things .

KevinH

[KevinH]

Found and fixed a bunch more bugs. Will post updated version tomorrow.

Ps use Sigil Tempfolder constructor and GetPath() and Sigil will create proper temp directory.

[varlog]

Kevin,

No,

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...

[KevinH]

Hi varlog,

Here is the bug fixed updates to the python scripts package for Sigil.

KevinH

[KevinH]

Hi varlog,

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

[varlog]

Ok, ok... you guru, me clueless... Will do it your way.

[varlog]

Not on the first page because it is not quite functional yet. The Sigil side of reacting to script is not ready yet. The summary widget is just a fake showing input parameters and output <wrapper />.
Scripts for wrapper have to have attribute standalone set to "false" in script manifest. Default is true: means standalone script without wrapper (old scripts should work).
Included are all known to me "wrapped" scripts with manifests, launcher (wrapper) with manifest and new xsd schema for script manifest. The scripts mostly fail.
Bumped up version to 0.0.8: the changes were too big for a small step .
For testing in real environment only.

[KevinH]

Hi varlog,

Thanks for posting a patch. But why are you keeping all of the old SigilAction stuff and the old script support? It simply makes understanding and debugging harder. I will build what you have here and then strip it away so that I can focus on testing the interface and getting something to a commit ready state.

If after we have everything working, you still want to add back support for the old script, you can add back that support then.

I should be able to build it tomorrow evening upon my return to town. Hopefully we can work together to get the result XML handling done.

Thanks!

KevinH

[KevinH]

Hi Varlog,

I just got home and I had some spare time tonight and was excited to see what you had put together so I grabbed the latest source and applied your 0.0.8 path. It applied cleanly but my build did not complete:

[ 70%] Building CXX object src/Sigil/CMakeFiles/Sigil.dir/Dialogs/PreferenceWidgets/ScriptWidget.cpp.o
In file included from /Users/kbhend/sigil/smaster/src/Sigil/Dialogs/PreferenceWidgets/ScriptWidget.cpp:36:
/Users/kbhend/sigil/smaster/src/Sigil/ScriptManager/ScriptInterface.h:35:10: fatal error: 'ui_ScriptInterface.h' file not found
#include "ui_ScriptInterface.h"
         ^
1 error generated.
make[2]: *** [src/Sigil/CMakeFiles/Sigil.dir/Dialogs/PreferenceWidgets/ScriptWidget.cpp.o] Error 1
make[1]: *** [src/Sigil/CMakeFiles/Sigil.dir/all] Error 2

I looked for the Form ScriptInterface.ui file all throughout the patch but I could not find it.
Perhaps you missed including this ui file for the patch? Or did I mess up in applying the patch?

Thanks,

KevinH

[KevinH]

Hi varlog,

I simply commented that line out to try and continue the build. The only other issue I ran into was that Mac OS X clang64 compiler really hated how you referenced ScriptManager::sigilScriptType::wrapper and library in ScriptWidget.cpp

Since sigilScriptType is actually a type (enum), the compiler actually just wanted the following:

type!=ScriptManager::library

and

type!= ScriptManager::wrapper

There was one other place inside ScriptManager.cpp itself that had the same issue.

Other than those two things, my build on Mac OS X completed. I will hopefully have time to start playing with it tomorrow.

Nicely done!

KevinH

[KevinH]

Hi,

Fired it up just before bed. I could not see how to tell the python interpreter where all of the launcher.py and is containers and wrapper codes are located.


Note: The plan is that everything in the launcher folder will become part of the Sigil distribution, and its path will be hard coded and known in the Sigil binary distribution. All python scripts would then be invoked through the launcher.py script.

You seem to have tried to do both old type scripts side by side with the new style and this just makes it harder to debug things. I am not even sure how to tell it where the launcher code is in the interface.

Please simplify things to just what we need for the new script architecture so that we can get things moving forward more quickly.

Thanks.

KevinH

[varlog]

Hallo Kevin,

Originally Posted by KevinH

... I could not see how to tell the python interpreter where all of the launcher.py and is containers and wrapper codes are located.
...

Launcher is just another python script, has to be installed, manifest is provided. For not-standalone scripts Sigil (ScriptInterface) invokes it with its folder as working directory and parameters as you rquired.

Originally Posted by KevinH

...
Note: The plan is that everything in the launcher folder will become part of the Sigil distribution, and its path will be hard coded and known in the Sigil binary distribution. All python scripts would then be invoked through the launcher.py script.

You seem to have tried to do both old type scripts side by side with the new style and this just makes it harder to debug things. I am not even sure how to tell it where the launcher code is in the interface.

Please simplify things to just what we need for the new script architecture so that we can get things moving forward more quickly.

For me the plan was and still is Generic Script Manager: python is only a part of it. Please indulge me in this case. We can hardcode python part later.

I've changed a few things since 0.0.8, will post it when I'm back home - which is in about 7 hours.

regards

[KevinH]

Hi Varlog,

For me the plan was and still is Generic Script Manager: python is only a part of it. Please indulge me in this case. We can hardcode python part later.

I've changed a few things since 0.0.8, will post it when I'm back home - which is in about 7 hours.

regards

This is NOT what we talked about. If you felt that way you should have stated that clearly up front. You never even once said you disagreed with me on the the overall scheme which is what I pitched to user_none and received his pre-approval on.

And python is not going to be hardcoded. It will just be the first language with a working container and launcher. User_none is thinking about adding support for the scripting language Lua on his own in a similar way.

Instead of giving me what I thought we had agreed on, you went your own way. You seem to have too much vested in keeping your own stuff. You simply should have said that was your goal from the beginning and I would have gone my own way right from the start.

Unless I hear back differently from you I will simply move forward on my own.

Take care,

KevinH

ps. FWIW: We could also have easily supported the original python scripts just by giving them their own type and passing it through the launcher (although that defeats the whole wrapper approach by risking that a script crash while writing files could bring Sigil itself down or lose work). Similarly that launcher or target python could have invoked any number of other script types.

[varlog]

Originally Posted by KevinH

...I will simply move forward on my own.

Ok.

regards

[KevinH]

Hi varlog,

Thanks for letting me know. Good luck with your project.

Take care,

KevinH

Originally Posted by varlog

Ok.

regards