Discussion on potentially removing tkinter plugins support

[KevinH]

What about importing the QtWebEngine parts? Do we want that in the light version? Or maybe the few apps that use that should import it directly from PySide6 so as not to cause QtWebEngine related bloat and WebEngine processes unless truly needed?

Thoughts?

[DiapDealer]

I'd prefer to reduce the amount of potentially unnecessary import bloat. Users still needed to import QtWebEngine from plug_utils into their plugin anyway (to get the PySide or PQt5 version), so I figure directly importing it from PySide6 should be no great hardship. In fact, I would rather they took over the importing of PySide6 modules themselves anyway. Just use plugin_utils_light for the wrapped QApplication functionality.

[KevinH]

Originally Posted by DiapDealer

I'd prefer to reduce the amount of potentially unnecessary import bloat. Users still needed to import QtWebEngine from plug_utils into their plugin anyway (to get the PySide or PQt5 version), so I figure directly importing it from PySide6 should be no great hardship. In fact, I would rather they took over the importing of PySide6 modules themselves anyway. Just use plugin_utils_light for the wrapped QApplication functionality.

Okay, for my limited use case of inline QFileDialog static functions, and no translations I will change to import QtWidgets directly from PySide. I will still keep the plugin_utils_light.py code inside the plugin in case I move to adding translation support at some point (which I probably should).

Thanks!

[DiapDealer]

Originally Posted by KevinH

Okay, for my limited use case of inline QFileDialog static functions, and no translations I will change to import QtWidgets directly from PySide. I will still keep the plugin_utils_light.py code inside the plugin in case I move to adding translation support at some point (which I probably should).

Thanks!

I figure it will work better to be able to do stuff like

from QtWidgets import QFileDialog

rather than need to use QtWidgets.QFileDialog and the like everywhere.

[KevinH]

For me it is only one or two lines, but yes in general you are right!

[wrCisco]

My 2 plugins cssRemoveUnusedSelectors and cssUndefinedClasses would require a bit of work to convert to PySide, but if the deprecation period would last one year as Kevin stated, that should be plenty of time to make the necessary adjustments.

[KevinH]

Yes there is no rush. We still haven't decided the final fate of tk use in plugins. Especially for those who make extensive use of it. I moved my plugins as it was a trivial 3 or 4 line change - ie. just low hanging fruit in case we decide to drop tk eventually. We will fully announce any official change here on MR and officially deprecate it for a full year of 3 or 4 releases.

I still need to look at all the plugins in our plugin index to see how much work that would be which will impact our decision I am sure.

So no rush and no need to even start conversion unless you are bored and retired like me!

[BeckyEbook]

@wrCisco: if I see correctly in my list also endNotesToParagraphs uses Tkinter.
But since it's a very old plugin (last release was 10 years ago!) you might want to leave it unchanged.

[DiapDealer]

I hope no one minds, but I moved several posts about tkinter from the Sigil release thread to its own thread here in the Plugins subforum.

[DiapDealer]

I've noticed some different behavior on different Windows machines when it comes to on-the-fly-theming of plugin pyside6 interfaces.

It seems to work on a Windows 11 machine, but on a Windows 10 laptop of mine, I need to rely on the match_sigil_darkmode function in plugin_utils to force a dark theme.

So for now, I'm recommending plugin devs pass "True" for the match_dark_palette parameter of PluginApplication of plugin_utils and plugin_utils_light. Just on the Windows platform. It safe to use the default "False" for Linux and macOS.

I was wrong about the two different windows dark themes above. The routine in plugin_utils will match either/or just fine.

The only downside here is that pyside6 gui plugins will not change themes on the fly (with system theme changes) on Windows with this strategy.

Hope that makes sense.

[KevinH]

Given Windows 10 is virtually at end of life, is there some way in python to see/detect the difference between Windows 10 and Windows 11?

Update: The dreaded Google AI gave me the following snippet:

    import platform

    def get_windows_version():
        """Detects Windows 10 vs Windows 11 based on build number."""
        if platform.system() != "Windows":
            return "Not Windows"

        version_info = platform.version()
        build_number_start_index = version_info.find('Build ') + 6
        build_number_end_index = version_info.find(' ', build_number_start_index)
        build_number = int(version_info[build_number_start_index:build_number_end_index])
        if build_number >= 22000:
            return "Windows 11"
        else:
            return "Windows 10"


    print(get_windows_version())

And if that AI found this routine someplace it should have that license. If it devised this just based on other language versions, then it should clearly state the license or say it is public domain.

[DiapDealer]

I'll look into that, thanks. But first I need to make certain that it IS a definite change in behavior from Windows 10 to Windows 11, and not just something else between the two machines that I'm overlooking.

I'd want to modify that code a good bit anyway. No need to do a string evaluation of the results (nor a need to handle non- Windows entry). I'd want to be able to call it using something simple like:

if iswindows and not iswindows11():
    match_sigil_darkmode()

Or perhaps iswindows10() so we won't have to remember to make changes when Window 12, 13 or 14 comes out.

[BeckyEbook]

Maybe this?

[wrCisco]

Originally Posted by BeckyEbook

@wrCisco: if I see correctly in my list also endNotesToParagraphs uses Tkinter.
But since it's a very old plugin (last release was 10 years ago!) you might want to leave it unchanged.

Ah, yes, it's a really old plugin for which I never opened a thread here on MobileRead. It was a workaround for flaws in old InDesign versions about the handling of foot and endnotes, but those are not an issue anymore (or at least not the same issue) and in the plugin index there are other plugins that handle the notes in a more flexible way, so I think I'll leave it be as a relic of a bygone era...

[KevinH]

I did take a look at ePubTidyTool as I know from this discussion that it uses Tk, just to see the extent of work. It makes heavy heavy use of tk for msgboxes, dialogs, main window frames, etc. So switching to PySide6 from tk for this plugin would be a non-trivial exercise and would require some real work. I am sure there are others out there that are in similar situation.

I wonder if instead of a deprecate and remove approach we should just deprecate Tk's use but not actually remove it just to discourage it use in new plugins? Or would that just put things off for a few years?