ui_slint#732
Conversation
|
Not bad at all. BTW it doesn't follow system theme on Linux. |
|
I'm gonna add an env var for changing default UI. |
|
Dark/light detection appears to work smoothly on mac and changes on the fly when the system setting is changed; on windows didn't test specifically the dark/light, and on linux according to searches system dark mode might not be detected or have issues depending on which desktop env is used. And also this: https://slint.dev/blog/default-native-style-change I've updated the Theme dropdown to include explicit Dark/Light variations specifically for OS's and DE's where dark detection does not work, so now it allows explicitly selecting Light/Dark even if it's not the current OS preference.
There is also https://pypi.org/project/darkdetect/ but it's an additional dependency and a crutch which supposedly fixes something that the OS + UI toolkit should do ootb, I guess better avoid it. |
|
slint gallery: https://docs.slint.dev/latest/demos/gallery/ |



Maybe this is too much, dunno, but felt like playing with this new rust-based UI toolkit (still in BETA) and thought that the best way would be doing something actually useful rather than hello-world stuff. Up to you to decide how useful this is, or if it's another toolkit to maintain with all the pains that come with it. I will fully understand if you decide to reject the PR - totally fine with me.
In any case, here it is:
Slint UI for PyGlossary
default (system) theme;

cupertino theme (light, can be dark too, selectable under Options > Theme)

Features
1.17.0b2Gotchas and WTFs
gcdeallocating objects when the thresholds are triggerred; this was solved by preventing any sling objects to be passed to threads and having to directly usegcmethods.. -- yes, this is ugly, and apparently, no nicer way exists or at least none of the 🤖 assistants could find a cleaner solution; this alone could be a sufficient reason for you to not want this inmaster. Having said that, the current code works without panicking and was tested to work on mac/windows/linux both when running from source and when running from nuitka binaries (some type of panics were only occurring with nuitka binaries but not when running from sources).slintis not a per se a python 'native' widget toolkit; it's rust-based, and python is among the other (~2nd hand) options as opposed to native rust.Limitations and workarounds
slint does not have it's own GUI file picker - they justify it by the need to keep the framework 'lean' and avoid bloat :D - the workaround that is applied is to delegate to whatever is available in the OS: for mac it's using
osascriptwhich can show a file picker, for windows WFP viapowershelland on linuxzenity/kdialog, all wrapped inpyglossary.ui.ui_slint.utils.pickOpenFile(). Surprisingly, this works seamlessly and shows native pickers on all three OS's.github actions are included for building slint nuitka binaries for mac and windows; was thinking to maybe add another one for building linux
AppImagesbut that will probably be in another scope, if ever. Before I always assumed that all linux users were able to compile anything from source, but keep discovering real people who use linux desktops and don't know how to install a.deb😆Overall I'd say slint looks promising with its flutter-style declarative syntax, but still too new and still far from the level of polish, robustness and googleability of pyqt, pygtk or even tkinter. The ball is on your side now, and I assume you know better what to do with this :D