Discussion on potentially removing tkinter plugins support

[BeckyEbook]

There is certainly a solution. Leave Tk, but encourage the development of new plugins with PySide6. More complex dialogs always require more work.

Additional incentives for those who would like to start writing their own plugins:

* Maybe an extension of the QtSigilPluginTemplate to add more controls.

* You should probably also update the first four posts in Plugin Development.
For example, the versions of the launcher in post #3 (it's a LOT of work if new features were additionally described) or the Plugin Framework (currently rev14) in post #4.

* Add interesting, proven features to the Post Your Useful Plugin Code Fragments Here thread.

Of course, these are just loose suggestions.

[KevinH]

Actually Post #3 is so out of date we should delete it. The wrapper.py version to Sigil version can actually be found by using our github site tags much more easily.

As for Post #4, nothing much has changed since the Sigil 1.0 timeframe in the plugin frameworks. That plugin dev manual is still valid. The plugin interface has been and continues to be backwards compatible. There are a few recent additions (I count 6 addition since 2019) but the fundamentals are unchanged. Even the current guide (14) does not include really recent changes. As with any dev project, the best way is to learn it is to read the source and see examples and we have quite a large number of python plugins for people to learn from.

Update:

Actually, the rev 14 version of the manual is up to date except for the latest commit that was introduced in Sigil 2.2 that allowed the plugin to see what if any font mangling algorithm was set to be used by the plugin.

See:

https://github.com/Sigil-Ebook/Sigil...2bf385c18f3ebb

I will further update it to rev 15 with that one missing interface call, and then remove all of the references to python 2.7 that still exist and maybe make it clearer that python 3.4 in the plugin.xml file only specifies the very minimum python version.

Update 2:
-----------

Added an out of date notice on Post #3 with a pointer to using github on the wrapper.py file for any specific Sigil release tag they might be interested in.

Added Sigil Plugin Framework at rev15 (consistent with current Sigil) and added it to Post #4.

[BeckyEbook]

This is a non-negotiable matter – analyzing the code of existing plugins is the best lesson.

[DiapDealer]

I have no problem with leaving tkinter in the bundles. Doing so on Linux and Windows is not that difficult. But I would like to strongly discourage its use for new plugins.

I never warmed up to tkinter gui programming. In fact, I probably hate it. Getting it to do the things I wanted it to do (in a consistent cross-platform manner) was as painful to me as I imagine self-dentistry would be. I consider it vastly more difficult to work with than PySide/PyQt. But perhaps that's because I understand Qt from the C++ side.

There's no real pressure to make a decision on this, so why don't we let it stew a bit, and upgrade the plugins that are under our control to PySide6? Offer help to those who show an interest in migrating. I figure the more PySide plugin code out there, the more likely it is that plugin devs will use that code for their new plugins.

I know a lot of people used my first tkinter plugins as templates/guidelines. I would have done the same in their shoes. We only had tkinter for while. That's why I bit the bullet and learned a bit about it. But when we started including PyQt, I jumped ship pretty quickly.

[KevinH]

That sounds like a plan. Perhaps I should add a paragraph on PySide6 to the latest plugin dev manual and try to also discourage Tk there as well.

Originally Posted by DiapDealer

I have no problem with leaving tkinter in the bundles. Doing so on Linux and Windows is not that difficult. But I would like to strongly discourage its use for new plugins.

I never warmed up to tkinter gui programming. In fact, I probably hate it. Getting it to do the things I wanted it to do (in a consistent cross-platform manner) was as painful to me as I imagine self-dentistry would be. I consider it vastly more difficult to work with than PySide/PyQt. But perhaps that's because I understand Qt from the C++ side.

There's no real pressure to make a decision on this, so why don't we let it stew a bit, and upgrade the plugins that are under our control to PySide6? Offer help to those who show an interest in migrating. I figure the more PySide plugin code out there, the more likely it is that plugin devs will use that code for their new plugins.

I know a lot of people used my first tkinter plugins as templates/guidelines. I would have done the same in their shoes. We only had tkinter for while. That's why I bit the bullet and learned a bit about it. But when we started including PyQt, I jumped ship pretty quickly.

[theducks]

Elephant in the room!

What does this do to to folk who are stuck at older versions of Sigil because their OS is 32bit or other reasons?

+1 on discourage use of TK in new ones.(as in it will NOT be added to the Plugin index )

[KevinH]

Well many of the older machines were Linux based, and DiapDealer's AppImage brought them kicking and screaming into the present!

As for 32 bit only users, Qt left them behind long ago.

And really old Sigil users (pre 0.7.2 through 0.8.x) do not have support for plugins at all, so no worries there. And no one is removing current plugins if the Sigil version they have supports them.

That said, if a user has a cpu capable of 64 bits but running a 32 bit version of their OS, I would strongly recommend upgrading to Linux.

So I do not think deprecating Tk but not removing it will have much of an impact on users of Sigil.

[DiapDealer]

And with the ability to use an external Python installation for plugins, Sigil users can create just about any Python environment for plugin use that they want for their aging versions of Sigil. The only limitation would be not being able to use plugins that use features not yet implemented in their version of Sigil. But that limitation affects them now even with the bundled Python.

They may not always be able to get the very latest updates for some plugins, but that's always been a risk already too. So I don't think people would be affected that adversely by any potential change in this direction.

[Doitsu]

I've got a cosmetic Sigil Qt question. When using file open/save dialog code such as the following code:

    app = QtWidgets.QApplication(sys.argv)
    fpath, seleted_filter = QtWidgets.QFileDialog.getSaveFileName(None, 'Save ePub3 as ...', suggest, "ePubs (*.epub)")
    app.quit()

on Windows machines, an ugly Python icon is shown in the task bar.
Apparently, this can be prevented by specifying the parent control instead of None.

How do I get the parent control?

[DiapDealer]

Originally Posted by Doitsu

I've got a cosmetic Sigil Qt question. When using file open/save dialog code such as the following code:

    app = QtWidgets.QApplication(sys.argv)
    fpath, seleted_filter = QtWidgets.QFileDialog.getSaveFileName(None, 'Save ePub3 as ...', suggest, "ePubs (*.epub)")
    app.quit()

on Windows machines, an ugly Python icon is shown in the task bar.
Apparently, this can be prevented by specifying the parent control instead of None.

How do I get the parent control?

This is what I've been using successfully for quite a while:

https://github.com/dougmassay/sigil-...s_light.py#L56

[Doitsu]

Since my plugin only has one QFileDialog importing the whole plugin_utils_light.py library might be a bit overkill.
I put a valid plugin.ico file in the plugin folder and used the following code, but the taskbar icon is still shown.

Spoiler:

def run(bk):   
    # check for supported versions
    if bk.launcher_version() < 20160707:
        print("This plugin requires Sigil 0.9.8 or later.\n\nPlease click OK to close the Plugin Runner window.")
        return -1

    def ensure_windows_taskbar_icon():
        if not iswindows:
            return
        import ctypes
        myappid = 'mycompany.myproduct.subproduct.version'  # arbitrary string
        ctypes.windll.shell32.SetCurrentProcessExplicitAppUserModelID(myappid)

    # Try to import PySide6, then PyQt5
    try:
        from PySide6.QtWidgets import QApplication, QFileDialog
        from PySide6.QtGui import QClipboard, QIcon
    except ImportError:
        try:
            from PyQt5.QtWidgets import QApplication, QFileDialog
            from PyQt5.QtGui import QClipboard, QIcon
        except ImportError:
            raise RuntimeError("No supported GUI framework found (PySide6 or PyQt5).")

    def get_file_path():
        ''' displays a file selection dialog '''
        app = QApplication(sys.argv)
        app.setWindowIcon(QIcon("plugin.ico"))
        ensure_windows_taskbar_icon()
        fpath, _ = QFileDialog.getOpenFileName(
            None,
            "Select LanguageTool Java file",
            "",
            "languagetool-commandline.jar (*.jar)"
        )
        app.quit()

        if not fpath:
            print("Plugin cancelled by user.")
            bk.add_result('info', None, None, 'Plugin cancelled by user.')
            return 0
        else:
            return fpath

What other parts of plugin_utils_light.py will I also need to add to get rid of the icon?

[KevinH]

Originally Posted by Doitsu

I've got a cosmetic Sigil Qt question. When using file open/save dialog code such as the following code:

    app = QtWidgets.QApplication(sys.argv)
    fpath, seleted_filter = QtWidgets.QFileDialog.getSaveFileName(None, 'Save ePub3 as ...', suggest, "ePubs (*.epub)")
    app.quit()

on Windows machines, an ugly Python icon is shown in the task bar.
Apparently, this can be prevented by specifying the parent control instead of None.

How do I get the parent control?

You could create a hidden QMainWindow to act as a parent but that just moves your problem to what to put as the parent of the QMainWindow I would guess.

[DiapDealer]

Originally Posted by Doitsu

Since my plugin only has one QFileDialog importing the whole plugin_utils_light.py library might be a bit overkill.
I put a valid plugin.ico file in the plugin folder and used the following code, but the taskbar icon is still shown.

Spoiler:

def run(bk):   
    # check for supported versions
    if bk.launcher_version() < 20160707:
        print("This plugin requires Sigil 0.9.8 or later.\n\nPlease click OK to close the Plugin Runner window.")
        return -1

    def ensure_windows_taskbar_icon():
        if not iswindows:
            return
        import ctypes
        myappid = 'mycompany.myproduct.subproduct.version'  # arbitrary string
        ctypes.windll.shell32.SetCurrentProcessExplicitAppUserModelID(myappid)

    # Try to import PySide6, then PyQt5
    try:
        from PySide6.QtWidgets import QApplication, QFileDialog
        from PySide6.QtGui import QClipboard, QIcon
    except ImportError:
        try:
            from PyQt5.QtWidgets import QApplication, QFileDialog
            from PyQt5.QtGui import QClipboard, QIcon
        except ImportError:
            raise RuntimeError("No supported GUI framework found (PySide6 or PyQt5).")

    def get_file_path():
        ''' displays a file selection dialog '''
        app = QApplication(sys.argv)
        app.setWindowIcon(QIcon("plugin.ico"))
        ensure_windows_taskbar_icon()
        fpath, _ = QFileDialog.getOpenFileName(
            None,
            "Select LanguageTool Java file",
            "",
            "languagetool-commandline.jar (*.jar)"
        )
        app.quit()

        if not fpath:
            print("Plugin cancelled by user.")
            bk.add_result('info', None, None, 'Plugin cancelled by user.')
            return 0
        else:
            return fpath

What other parts of plugin_utils_light.py will I also need to add to get rid of the icon?

Hmmm... what you have should really be enough--provided you have the iswindows piece from plugin_utils_light.

I don't see any app.exec() though. So I'm not sure your QApplication (and its icon) is technically being utilized. Try inserting it (app.exec())after the call to ensure_windows_taskbar_icon().

[DiapDealer]

You can also try using an empty QWidget:

w=QWidget()

and using that as the parent parameter in getOpenFileName()

I do something similar in my KindleImport plugin (which also only uses the FileOpen widget):

https://github.com/dougmassay/kindle...ilities.py#L45

It uses the wrapped QApplication from plugin_utils.py, but that should not be strictly necessary to get things to work.

[Doitsu]

Originally Posted by DiapDealer

You can also try using an empty QWidget:

w=QWidget()

and using that as the parent parameter in getOpenFileName()

Unfortunately, that didn't work either.
Since this is mostly a cosmetic issue, I won't waste any more time on it.