Discussion on potentially removing tkinter plugins support

[KevinH]

And maybe it is time we think about dropping Tk support for plugins given we now fully support PySide6 which is much more reliable and stable, and much better documented than the Tk library.

We could probably individually help what few remaining plugin devs move away from tk to Qt. I know I still use Tk in FolderIn/FolderOut and maybe a few other plugins but it would be trivial to replace as I never liked coding in Tk.

Thoughts?

[BeckyEbook]

Originally Posted by KevinH

And maybe it is time we think about dropping Tk support for plugins given we now fully support PySide6 which is much more reliable and stable, and much better documented than the Tk library.

This is indeed true, but doing a quick check, these plugins use Tk nevertheless quite a lot, say 50 out of 200 plugins found in the real world, that is 1/4. Maybe the overall number is a little smaller, because I have already met plugins that had import tkinter in the code, but did not use it at all. Many of them are probably rarely used or almost forgotten, but nevertheless they exist and they are the power of Sigil extensions.

If I find a free moment, I will prepare a broader overview, and a separate thread can be created related to the update of these plugins.
I won't do it soon, because I have a lot of work in the garden, but if we are talking about giving up Tk support it is probably worth thinking about it carefully.

[Doitsu]

Originally Posted by BeckyEbook

[...]If I find a free moment, I will prepare a broader overview, and a separate thread can be created related to the update of these plugins.

Unless I missed one, only 3 of my plugins still rely on Ttk:

1. ODTImport
2. PrincePDF
3. FootnoteLinker

The first two only use the Tkinter file selection dialog and can be easily upgraded. The last one requires a new Qt GUI.
I'll try to upgrade all of them by the end of June.

[KevinH]

We are just thinking about it, no decisions have been made until we see how much Tk is out there that would be non-trivial to change. If we do decide against keeping Tk, it would have to be deprecated for one year of releases at least.

We are really just thinking out loud because building and maintaining tk/tcl is a pain, and its performance can be flakey.

[DiapDealer]

I'll be honest: at this point, I wouldn't blame anyone for not worrying about providing support for pre-2.0 PyQt5. Just leave a version that still works with pre-2.0 Sigil and make a new one that works with PySide6. With the AppImage and the ability to use virtual Python environments for plugins, there's very few people that can't get PySide6 available for Sigil plugins.

Of course anyone who wants to continue using plugin_utils as a compatibility layer between the old and the new will receive bonus points!

[KevinH]

Originally Posted by DiapDealer

I'll be honest: at this point, I wouldn't blame anyone for not worrying about providing support for pre-2.0 PyQt5. Just leave a version that still works with pre-2.0 Sigil and make a new one that works with PySide6. With the AppImage and the ability to use virtual Python environments for plugins, there's very few people that can't get PySide6 available for Sigil plugins.

Of course anyone who wants to continue using plugin_utils as a compatibility layer between the old and the new will receive bonus points!

For my bonus points ...

Here is all it took to get FolderIn to ask for a folder to read in from in an inline manner (ie. no MainWindow needed)

from plugin_utils import QtWidgets

...

    # ask the user to select the source folder to load files from                                                       
    app = QtWidgets.QApplication(sys.argv)
    foldpath = QtWidgets.QFileDialog.getExistingDirectory(None, 'Select Folder to Input Into Sigil', basepath)
    app.quit()

And here is how to ask for a filepath and name to save a file into:

    # ask for name and location to save
    app = QtWidgets.QApplication(sys.argv)
    fpath, seleted_filter = QtWidgets.QFileDialog.getSaveFileName(None, 'Save ePub3 as ...', suggest, "ePubs (*.epub)")
    app.quit()

which replaced all of this tk required for MacOS

    import tkinter
    import tkinter.ttk as tkinter_ttk
    import tkinter.constants as tkinter_constants
    import tkinter.filedialog as tkinter_filedialog

...

    # ask the user to select the source folder to load files from
    localRoot = tkinter.Tk()
    localRoot.withdraw()
    if sys.platform.startswith('darwin'):
        # localRoot is is an empty topmost root window that is hidden by withdrawing it
        # but on OSX localRoot needs to be centred, and lifted and focus_force used
        # so that its child dialog will inherit focus upon launch
        localRoot.overrideredirect(True)
        # center on screen but make size 0 to hide the empty localRoot
        w = localRoot.winfo_screenwidth()
        h = localRoot.winfo_screenheight()
        x = int(w/2)
        y = int(h/2)
        localRoot.geometry('%dx%d+%d+%d' % (0, 0, x, y))
        localRoot.deiconify()
        localRoot.lift()
        localRoot.focus_force()
    foldopt = {}
    foldopt['parent'] = localRoot
    foldopt['initialdir'] = basepath
    foldopt['title'] = 'Select Folder to Input into Sigil'
    foldopt['mustexist']= True
    foldpath = tkinter_filedialog.askdirectory(**foldopt)
    # localRoot.destroy()
    localRoot.quit()

Admittedly, a lot of the differences were only required on MacOS as Tk did not work reliably across platforms.

I am going to use the same approach for FolderOut, and ePub3-itizer. My Access-Aide plugin already moved to Qt because Tk does not work well with svg images and its fill in alt text dialog was really flakey.

And to restrict plugin code to run only on Sigil 2.0.0 or later:

    if bk.launcher_version() < 20230315:
        print("This plugin requires Sigil-2.0.0 or later")
        return -1

So if I keep the old k version for All pre-2.0 Sigil as one plugin, I can then release this as a new version of the plugin to run on Sigil 2.0.0 and later. And no one gets left behid so to speak.

[KevinH]

FWIW using the approach I outlined earlier, I was able to remove all use of tk from my plugins that used it previously:

FolderIn
FolderOut
ePub3-itizer
cfitest
sampleOutput (updated so it works for non-standardized epub layouts)

Access-Aide, BibiReader, EpubJSReader, and ReadiumReader already have moved to PySide6, and none of the following needed or used a gui of any sort so are okay as is:

LOI-Generator
RemoveInLineStyles
Template2
Template3
TOCSaver

Once we decide on a reduced plugin_utils.py or not. I will release them (all restricted to Sigil 2.0.0 or later)

If anyone wants to see them to get ideas just pm me.

[DiapDealer]

Originally Posted by KevinH

Once we decide on a reduced plugin_utils.py or not. I will release them (all restricted to Sigil 2.0.0 or later).

I took a preliminary shot at removing anything that wasn't relevant to Sigil 2.0+ in plugin_utils_light.py.

I'm sure there will be kinks to work out (and I surely had to break something) but it's a start!

https://github.com/dougmassay/sigil-plugin-utils

[KevinH]

Originally Posted by DiapDealer

I took a preliminary shot at removing anything that wasn't relevant to Sigil 2.0+ in plugin_utils_light.py.

I'm sure there will be kinks to work out (and I surely had to break something) but it's a start!

https://github.com/dougmassay/sigil-plugin-utils

Great I will do my testing with the light version.

Thank you.

[DiapDealer]

It's basically the wrapped QApplication and a few utilities. Stuff to match fonts and colors with Sigil and the like. Also useful for automatically loading translators (including qtbase translations). If none of that stuff is relevant, or important to a plugin, one might choose to forego its use completely.

[KevinH]

In my testing on MacOS the plugin without the wrappered QMainWindow sees the Dark vs Light changes on its own? Does it work like that on Windows? Is it only Linux that needs the wrapper?

[DiapDealer]

Windows was the one that typically needed to manually match light/dark. But even that might have changed by now. Qt6.5 was a bit of a game changer there.

[KevinH]

FWIW, I tested the PySide6 plugins (not using the wrappered MainWindow) and even on Linux (Manjaro with your AppImage) with the KDE Plasma 6 Desktop, the plugin nicely changed themes when the system theme changed (even when the gui filedialog was open). So it detected the change on the fly and handled it.

So unless Windows still needs the wrappered MainWindow, we probably do not need even that anymore.

[DiapDealer]

I'm pretty sure Windows still does, but I'll double-check to be sure.

Remember that it's QApplication that's being wrapped. That's how it makes it easy to load translators for qtbase strings, and for the plugins' strings themselves. It also allows fonts to be matched from Sigil to plugin. Matching Sigil's dark palette is false by default in the wrapped QApplication. So if plugin devs do nothing with the match_dark_palette parameter, that functionality will be skipped anyway.

OK, I checked, and on Windows the Qt plugins will auto switch when going from light to dark and back. But left to its own devices, PySide6/Qt will always use the inherent Windows dark palette. Meaning if a Windows Sigil user is using Sigil's custom dark palette, the plugins won't match Sigil's dark color palette. Not a huge deal to me if plugin devs don't want to worry about it, but I'd like to leave the option to match the dark palette in there (but defaulting to false) for those that might want to.

Remember... I have no reservations about plugin devs avoiding the plugin_utils (full or light) altogether if they do choose. If we remove the wrapped QApplication from the light version, then that's essentially what they'd be doing anyway. There'd be nothing left for it to do.

[KevinH]

Originally Posted by DiapDealer

I'm pretty sure Windows still does, but I'll double-check to be sure.

The way the PluginApplication handles translations is really nice anyway, so keeping the light version is useful in and of itself.

But the light version generates the following error message due to a slight dropped import of qVersion.

  File "/Users/kbhend/Library/Application Support/sigil-ebook/sigil/plugins/FolderIn/plugin_utils_light.py", line 41, in <module>
    PLUGIN_QT_MAJOR_VERSION = tuple(map(int, (qVersion().split("."))))[0]
                                              ^^^^^^^^
NameError: name 'qVersion' is not defined
Error: name 'qVersion' is not defined

which can be fixed by preceding qVersion() with "QtCore.". I made that change to my copy and it seems to all work just fine.