Plugin Development

[DiapDealer]

Originally Posted by Vroni

or is something availöable in the API to make use of?

We've been mentioning the new stuff available in the api all along.

There's the group functions which return the locations of the different mimetypes (where are the xhtml files being kept, where are the css files stored, where is the opf?). Then there's still the href from the iter functions that can be used in combination with the group data (or the relative link between two hrefs just discussed) and other things.

It's not a matter of not being able to "trust" that certain locations will be present. It's a matter of switching to new methods/paradigms that don't make hard-coded assumptions about where things always used to be.

Examples of all this are in the plugins that have already been updated to accommodate non-standard (as well as standard) epub structures.

If you have any specific code-related questions as to how to perform a certain task, feel fee to ask--in words OR in Python.

[KevinH]

Yes bk.addfile() still works as before. It will check the filename to make sure it is unique and the add the file to the current default folder for that file group. The id is returned and you can always do a bk.id_to_bookpath() routine to get the resulting bookpath.

Or you can get the folders to be used via file group and choose among them if there is more than one, etc.

Or you can create your own bookpath and pass that to the new way to add a file.

[Vroni]

Creating a new xhtml file. Currently i "just" need to place an entry in the spine (getspine; setspine) and then just call addfile. Theres no other place it can go right now as in the TEXT folder. In the new version, it can go anywhere and i have to query the user where it should be stored...

Vroni

[KevinH]

Or just do as before and use the default folder for that group (type of file). Actually, I think adding an xhtml file in the plugin should auto handle the spine for you (but it has been a long time since I checked that code).

[DiapDealer]

Originally Posted by KevinH

Or just do as before and use the default folder for that group (type of file).

Agreed.

You're free to query the user for as little, or as much info as you like. They didn't have a choice in where your newly-created xhtml file went before, and they don't really need a choice now (unless you want to give them one). The physical location of the xhtml file in the archive has no functional relevance to how the epub will render. That is taken care of by the spine section in the opf. If after your plugin is done, the user doesn't like where the file is physically located, we've given them the tools to put it wherever they want.

[KevinH]

For the upcoming release of Sigil, we have added some capability to use dark mode because for some end-users who use plugins, the white background of a plugin gui elements may be a bit jarring under dark mode.

For plugins using tk widgets on macOSX, the tk widgets will automatically take on the dark mode of macOS as long as a recent (version 8.6.10 or later) release of TCl/Tk is installed on the system and Python 3.7 has been compiled against it. The next macOS release of Sigil will have been properly compiled to support dark mode. So macOS users with a recent Tcl/Tk version should get dark mode with no further work.

For plugins that use pyqt5 (or tk on platforms other than macOS), we have extended the plugin interface to provide some colour related information as follows:

    # New in Sigil 1.1                                                                                              
    # ----------------                                                                                              

    # returns "light" or "dark"                                                                                     
    def colorMode(self):
        return self._w.colorMode()

    # returns color as css or javascript hex color string "#xxxxxx"                                                 
    # acccepts the following color roles in a case insensitive manner:                                              
    #    "Window", "Base", "Text", "Highlight", "HighlightedText"                                                   
    def color(self, role):
        return self._w.color(role)

Sigil master now supports these routines for bk.launcher_version() >= 20200117:

Plugin developers will be able to determine if the system/Sigil is using dark or light mode and get some basic colour information (#XXXXXX). Using this additional information, plugin developers could change their gui to use these colours (in either or both light and dark modes). The colour roles used here match the colour roles used in Qt. See QPalette and etc.

Hope this helps,

KevinH and DiapDealer

[DiapDealer]

A crash course for those who roll their own Sigil and want to get a head start on dark-theming their PyQt5 plugins:

from PyQt5.QtWidgets import QApplication, QWidget, QStyleFactory
from PyQt5.QtGui import QColor, QPalette
from PyQt5.QtCore import QCoreApplication, Qt

def dark_palette(sigil_colors):
    p = QPalette()
    dark_color = QColor(sigil_colors("Window"))
    disabled_color = QColor(127,127,127)
    dark_link_color = QColor(108, 180, 238)
    text_color = QColor(sigil_colors("Text"))
    p.setColor(p.Window, dark_color)
    p.setColor(p.WindowText, text_color)
    p.setColor(p.Base, QColor(sigil_colors("Base")))
    p.setColor(p.AlternateBase, dark_color)
    p.setColor(p.ToolTipBase, dark_color)
    p.setColor(p.ToolTipText, text_color)
    p.setColor(p.Text, text_color)
    p.setColor(p.Disabled, p.Text, disabled_color)
    p.setColor(p.Button, dark_color)
    p.setColor(p.ButtonText, text_color)
    p.setColor(p.Disabled, p.ButtonText, disabled_color)
    p.setColor(p.BrightText, Qt.red)
    p.setColor(p.Link, dark_link_color)

    p.setColor(p.Highlight, QColor(sigil_colors("Highlight")))
    p.setColor(p.HighlightedText, QColor(sigil_colors("HighlightedText")))
    p.setColor(p.Disabled, p.HighlightedText, disabled_color)

    return p

class MyQWidget(QWidget):
    def __init__(self, bk, prefs):
        blah
        blah
        blah

def run(bk):
    prefs = bk.getPrefs()
    supports_theming = (bk.launcher_version() >= 20200117)
    app = QApplication(sys.argv)
    if supports_theming:
        if bk.colorMode() == "dark":
            # The Windows Sigil darkmode is created with the Fusion style as
            # the basis for Sigil's dark palette. Macs may prefer starting elsewhere.
            # Though "Fusion" should suffice for all three platforms without a lot of fuss.
            app.setStyle(QStyleFactory.create("Fusion"))
            app.setPalette(dark_palette(bk.color))
    ex = MyQWidget(bk, prefs)
    ex.show()
    app.exec_()

Clearly you'd have to create your own MyQWidget class in this case, but I leave that up to you. There's many ways tackle creating PyQt5 plugin interfaces. That's nothing to do with theming. I should have a working version of my DOCXImport plugin that will support dark-mode ready for uploading soon. So people will be able to copy/paste from that as well.

[HaPeSchu]

I am currently trying to limit Search&Replace of text within HTML pages to find only "real" texts, nothing outside the body element, not searching in elements, attributes and so on.

MY idea is just to crawl over all HTML pages with the Quickparser and do a s&r only in the text section.

I guess there is nothing in place to get the actual s&r settings inside the plagin? I do not wanmt to build my own dialog as i would like to have access to my saved searches and i dont want to duplicate all the coding.

Thx in advance

//HP

[DiapDealer]

No. There is no way to get the ui search parameters into a plugin.

While I understand the desire to not reinvent the wheel, keep in mind that Sigil uses PCRE regex and python plugins use either the re module or the regex module. And while they're all very similar, it's conceivable (and actually likely in the case of complex expressions) that the same saved expressions will not produce the same results when using different regex implementations. There are also syntax differences to take into consideration.

The bottom line is that even if there were a way to do what you want, only the simplest of expressions would be able to be used interchangeably.

[KevinH]

And the problem is not search. Search outside of tags is easy and Sigil already has that capability. The hard one is replace. For example a simple word pair such as "good day" might it fact have span tags or italic or bold tags around only one of those two words. So for each word (and even partial words such as word starters with dropdown first letters) you would need to store and remember its parent tag so that when it comes time to replace, you are not accidentally removing mark up or destroying its well-formedness.

[KevinH]

That said search and replace of a single word using regex to exclude tags from the search is already doable in Sigil as well with regex.

[Doitsu]

Originally Posted by HaPeSchu

MY idea is just to crawl over all HTML pages with the Quickparser and do a s&r only in the text section.

BTW, Sigil also comes with a custom version of BeautifulSoup, which, IMHO, is much easier to use than Quickparser.

[HaPeSchu]

Originally Posted by KevinH

That said search and replace of a single word using regex to exclude tags from the search is already doable in Sigil

I never mentioned that i only want to do to replace a single word. And the existance of other elements inside "good day" is very well visible in code view. Sorry, i dont understand this "argument".

I wasnt able to figure out how to change double quotes to single quotes in Sigil

Originally Posted by KevinH

as well with regex.

and i dont understand the difference between "using regex to exclude tags from the search is already doable in Sigil" and "as well with regex". Two choices? One is "using regex" and the other is "with regex"?

But before confusing me: as Diap said that in-plugin Regex has a different flavor as in-Sigil its not worth thinking of a plugin any further as i dont want to have my regex doubled and maintain both of them.

[Doitsu]

Originally Posted by HaPeSchu

But before confusing me: as Diap said that in-plugin Regex has a different flavor as in-Sigil its not worth thinking of a plugin any further as i dont want to have my regex doubled and maintain both of them.

For the most part the differences are actually negligible.

[HaPeSchu]

Still the problem remains that I have no access to the saved searches