GTK alternative #1322
Comments
|
This would probably require way more effort than using either Qt or GTK. If Qt wouldn't cause any major crashes, we wouldn't even think about switching GUI and besides Qt the best option is likely GTK because a lot of other software uses it. It also fits our license and there are official Python bindings for it. |
|
It's actually not just about widgets. If you use the Qt framework, you have got a Qt application with some program logic and configuration written in Python. If you use tkinter, you have got a Python application with some user interface done with tk. So you can keep the data model and the controller part almost completely free of tkinter imports, but you have to do all the work yourself. I suspect that it is easier to port a Qt application from Python to another language like C++ than to replace the GUI framework and reuse the Python code. I have not yet found the GTK code here, but I assume that the Manuskript application will have to be reimplemented in large parts. On the other hand, tkinter is very fast and stable. The usual widgets are mostly the same as elsewhere, so there are no problems. You have to struggle with the geometry manager for every specially placed scrollbar, but so far I have found an excellent answer to every question on StackOverflow. For a writing program such as Manuskipt or novelWriter, it depends on the tree view widget and the text input control. Just as a proof of concept, I programmed a lightweight writing application with tkinter. It is named mdnovel, and for the sake of simplicity, it works with Markdown throughout. The file format is also Markdown with YAML inserts, similar to Obsidian. Anyone who wants to get an idea of the potential of the tkinter GUI can play around with it. |
You can find it in a separate branch here: https://github.com/olivierkes/manuskript/tree/gtk |
|
Well, yes, thanks. I did take a look at this branch, but when I opened random files I noticed a lot of PyQt imports.. But at second glance, I can now see some GTK related code, e.g. in the editor package. How do you rate the progress of the porting? It's been going on for quite a while, hasn't it? |
My problem is that I'm still mostly working on other software. So I only spend some left over time on it. A lof of Manuskript code lives in the main editor for writing, using tools like spell checkers and such (also smaller things around the editor like the timeline, plots tab with metadata and more). That is still missing. You can already open projects with the GTK port, even make changes and save them. But it requires quite some effort to make everything match the original code base. Maybe next year I will find the time to just go through all of the missing things. After that it will require testing and I plan to still make at least one release with Qt and GTK in parallel. So people can directly compare both and call out broken or missing functionality since test cases can only go so far as developers think about. ^^' The major advantage of the GTK port is definitely the restructured IO code and data model. It's a night and day difference in terms of reliability, maintenance cost and even speed at the same time. I wish I could simply take these changes and back port them into Qt... but because this code base is so all over the place, mixing GUI, data access and IO, I don't even think this would require less work than completing the GTK port... or at least less annoying work. ^^' But if anyone in the mean time would try to pull off a PR doing that, I would happily merge it of course. Otherwise it's always nice to see if people contribute, be it fixing bugs or working on new features. |
|
Yes, that looks like a lot of work. But Qt isn't actually a broken platform, is it? Wouldn't it make more sense to stick with it and clean up the Manuskript code instead? Well, I'm sure you asked and answered this question yourselves quite a time ago, so it's certainly none of my business. But I would be interested to know what your motive is for taking on such a large project. I mean, traditionally you maintain an open source project because you want to use it yourself. That's how I do it anyway, with exceptions of course when it comes to smaller programs, sporting exercises so to speak. |
|
From my perspective over the years Qt is broken. At least if you are using Python as with Manuskript. Maybe it can actually be acceptable with C++ but I didn't want to port to a different language, potentially dropping all contributors. Also I think Python makes it much easier for many developers to contribute thanks to its readability of syntax and its popularity. The main problem with Qt is that it allows custom themes which may fully break applications and I don't mean, applications look weird. No, what you get as bug report is the application crashing out of the blue on many different systems. Only common factor is users which apply a custom theme to the application which causes somehow an memory access issue. So you end up with a segmentation fault inside Qt that you as application developer can't fix. How to solve it? Report it towards Qt developers who are split into one group of commercial developers and one group behind KDE, I assume. You would think this problem is known when we are speaking about a cross platform application stack on desktop and mobile, right? But then we are already using PyQt5 which isn't the official binding of Qt5 in the first place and Qt5 is already dated in comparison to Qt6. So likely the only answers you get is to port from Qt5 to Qt6 and use the official APIs... But then we are talking about a complex application I didn't originally start developing. I don't know all details about Qt5, differences between it and PyQt5 and all changes required to port it. Additionally I'm not convinced going down the rabbit hole to Qt6 would magically solve everything. From everything I have experienced with the current code base, I can say I don't like how the MVP (model viewer controller) concept is implemented in PyQt5. I think it makes everything worse for maintenance by making code pieces divided into chunks all over the place. I don't like how it deals with handling UI files (made in Qt Designer). It essentially generates Python code out of the UI files which makes everything slower as necessary during runtime. In comparison GTK simply reads an XML file and that IO part is just invoked via Python API but implemented in C. So it's way faster. If I had started Manuskript I would probably used a different GUI toolkit. These days I am most experienced with GTK. The documentation is pretty solid. The Python bindings are officially supported and don't seem to be a second class citizen. In the end I just want to avoid a software stack that causes unnecessary friction and currently Qt seems to do just that. Also I haven't even started with the issues I had to deal with when using PyInstaller in combination with PyQt... Making it run on Windows required me to delete certain DLLs from the generated build by PyInstaller which were not even required in the first place. For example PyInstaller would automatically bundle QtBluetooth.dll with it for some reason which caused errors on startup... and no, Manuskript isn't using Bluetooth in any way, ever. I have never seen something as bizarre with GTK because it's not a toolkit that bundles an abstraction layer for everything possible at once. It's separated into different projects to make dependencies clear and precise. For Qt it only works on Linux with proper package management like that. |
|
Thank you for the insights. This confirms my choice of tkinter for my own application, which I use under Windows, but which should also work under Linux. If I had switched to Linux instead of Windows 11, as I had once planned, GTK might also have been an option. |
|
Would Tauri (akin to Electron) be a more ideal alternative if not Tkinter? It could allow users to work in a browser or desktop environment. |
|
If you want to redesign the application from scratch in a different programming language, that would be worth a look. |
Yes, a brief look into the code confirms this. However, to me this doesn't seem like a PyQt problem, but a Manuskript architecture problem. It looks like the application is built up primarily around its GUI, with File IO that reads and writes directly from/to the view's data representation. If there was a GUI-agnostic data model implemented in pure Python, and a view that just uses Qt widgets as if PyQt were a simple GUI toolkit, and provided an abstract API for messaging like a facade, a lot of problems would be solved. In any case, this was my approach when designing my own novel writing program using tkinter, and this is why the OP's initial suggestion isn't totally wrong. The reason we spend our time programming open source software is because it's fun. To me, it looks like the Manuskript GUI migration is lagging, because replacing Qt references with GTK ones while maintaining the basic architectural structure is no fun at all. |
|
I mean in the end the only relevant question is: Who does it? If there's a person who wants to use Tkinter over GTK, be my guest. There's already an implementation of the model which isn't directly linked to the GUI in the GTK branch. That can be used with any GUI theoretically. |
|
Right, thanks for the hint. I missed that because I was looking around in the load_save package which seems to work with the Qt data types. |
Since Manuskript is being ported to GTK from Qt, would it be better to use a Tkinter (GUI Toolkit)? It is programmed using Python, which is also the primary language of Manuskript. It has built-in widgets, though less than GTK and Qt. Notwithstanding, custom widgets can be developed to further its features (akin to Qt and GTK).
The text was updated successfully, but these errors were encountered: