Please do take a shot at the glue code if you have any interest. Yes QVariants are used to pass things. And PythonRoutines is an example of how we do the interface with the embedded python at least for a few functions. There are other cases where we skip PythonRoutines in a few places in the code but not many.
The embedded python interface/bridge does have a few restrictions, it will not pass maps but will pass lists of strings, lists of lists, or a pointer to a python Object. etc. To pass maps, I pass a keys list and values lists and build the map on the other side of the bridge. Just let me know if you have any questions.
Having cssselect be required for Sigil to function is not really an issue as all of lxml is already required for parsing and fixing pure xml files like the opf and the ncx during Sigil start-up.
That said, if we can get a gumbo based query working we can instead focus on a better selector parser in C++ or even do the parsing in python in css_parser and pass back what to query for.
There are lots of ways we could take this.
I will try to get gumbo-query building and running with our sigil specific gumbo and at least try a query and see if its jQuery-like selector interface works.
Thanks,
KevinH
Quote:
Originally Posted by wrCisco
Well, the idea of integrating the plugin's code into Sigil intrigues me, I'm almost tempted to try to write the glue code myself, if I may...
(As to the practical problem on how to integrate the code: one would need to put the appropriate python module in the python3lib directory and then write one or more c++ methods for the PythonRoutines class, which afterward could be called from elsewhere in Sigil, right? QVariants as arguments seem sufficiently harmless if one restrain themselves to numbers and strings - or lists of numbers and strings - I guess...)
But the integration wouldn't be a completely straight forward change:
- The code of the builtin Delete Unused Classes is a sort of specialization of the Sigil's Reports tool (which has the same flaws of the "Delete..." functionality in "Classes Used" and "CSS Classes"), so the code of the plugin would require some refactoring if we want to serve that as well.
- The python package cssselect, which now is only required to run plugins, will be required to run Sigil itself.
- There are two things in which the builtin Delete... is more thorough than the plugin: it looks for matches only in the xhtml files where a stylesheet is linked, and it collects selectors from <style> tags too, while the plugin is more conservative: it always looks for matches in every xhtml and xml file, and never considers <style> tags. The philosophy has always been to stay on the safe side of the error: it's better to leave some useless cruft than to remove some useful code. This, however, would probably not be good enough for a complete report on usages (so, more refactoring, or accepting a suboptimal system).
As to integrate also cssUndefinedClasses, I'm not contrary in principle, and I understand that from a user point of view the two plugins do something very similar, but from the developer point of view they are two different beasts (apart from a few GUI functions, the only thing that they have in common is the css parsing).
Combining rules, as Kevin pointed out, is in general trickier than it seems: it would be safe and not overly complicated only if the selectors were an exact match and the rules were one right after the other (as in the example of Turtle91, but that is the only case).
So, I'm not 100% sure of what would be the best course of action now: maybe wait to see what Kevin can squeeze out of the gumbo query library?  |