Project future, maintainability concerns and suggestions on how to improve the project

[frica]

Hello everyone,

Disclaimer: I have a lot of respect for open-source maintainers and I'm grateful to @TomSchimansky for this toolkit. There is certainly some context I miss and I apologize if it was discussed before.

I came across CTk very recently. I've been looking in the last months at many UI frameworks for Python. Tested a few, looked at their repo and also how active they are. Some frameworks look good, some are easier than others, most modern solutions are "web-based" (= involve some kind of web-server for the rendering) which is overkill in some case for desktop applications.

I never liked Tk. The default UI output has been always bad, whether it was 20 years ago or today. But CTk fixes that rendering issue and make it more rewarding to overcome the Tk layouting logic. The documentation is also pretty good. So thanks to the people involved for all the efforts!

But:

• There are bugs though. 330 as I write this.
• 47 PR are open today.
• There have been 5 PRs from external contributors merged to main the last 12 months.

So I see only one maintainer. I see PRs waiting for a while. I see active and knowledgeable people in the issues discussions but no one has the authorization to triage the incoming issues, nor merge the valuable PRs. I see no plan for the future.

I don't know how it's organized internally between the maintainer and the long time supporters/technical experts of CTk. But I think it's possible to improve the repository and project state with a few steps:

• add a file to explain how to help (see example here)
• set a better template for the issues to avoid low-quality bug reports
• give rights to a few people on Issues/PR/Discussions. This would allow for instance to close faster obvious irrelevant defects/PR (like Delete examples directory #2287 or It's finally published to GitHub. #2311), move discussion posts from one category to another, tag issues as bug, enhancement etc. This would help the maintainer to have a cleaner state when he has time to look at the repository
• Let contributors update documentation by providing publicly the documentation files
• Allow 1 or 2 key contributors (chosen by the maintainer of course) to merge PRs (to be decided which ones)

Tell me what you think about these ideas and let's openly discuss about the topic in a polite and constructive manner.

Regards,

Fabien

[JanPanthera]

Maybe we someday create our own, since Tom seems not active anymore

[JanPanthera]

I mean we could write our own using opengl or even vulkan, 😹
This would be way faster then tk xD

[frica]

That's an ambitious idea, way above what I can offer as help 😄

[JanPanthera]

Me too, but it would be fun. Some C++ or doing it in python, i am really mad with this slow tk an this overblown qt lol

[Akascape]

@JanPanthera I also found this dearpygui library based on c++, which is actually good in performance. It's perfect for building feature rich python projects.

[JanPanthera]

From the name it hears like rip off from dearimgui xD, anyway i need to complete my current project until i can start have fun with c++ or opengl/vulkan in python 😹
I coul be done with my tool but i strangely have to code my own widgets.... TreeView... hust hust

[Akascape]

@TomSchimansky If you wish, I can manage the issue and discussions.
I regularly check the discussions and issues tab, so I will try to close unnecessary/duplicate issues, convert some of them to discussions, and closing fixed issues.

[TomSchimansky]

I need to move the repository to an organisation in order to assign people with moderation rights only but i will think about it 👍

[TomSchimansky]

Hi @frica, I briefly wanted to let you know that I noticed your post and I am totally aware of the situation and the problems you mentioned. I am finishing my Bachelor thesis at the moment and I dont have any time left to work on this project at the moment. However this will change in 5 weeks and then I will start to clean up the issues and address the most important bugs. I never could bring myself to the point of assigning collaborators because I thought, and still think, that this project is not suited very well for collaborative development. There are so many workarounds and hacks used to make this library work which I dont understand myself after some time. And if one merges a pull request without being aware of these or without proper testing it could be that functionality breaks but only on certain operating systems and so on. The makeshift nature of this project is also what kept me from working further on the project because I saw no future for it because of all the workarounds and the disappointing performance. But as so many people are still using the library I might get motivated enough after my thesis to start addressing the most important bugs and feature requests. I will also think about assigning collaborators, at least for moderation. Only a little patience is needed until then. 🙏

[frica]

Hey Tom,

Thanks for taking the time to respond. As stated in my original post I didn't know much of the context and I'm glad you could clarify the state of the project. My suggestions were meant to provide some help and guidance, and I'm not pretending I could do better at all :)

I also understand your situation, no worries. My point of view is that your toolkit seems to have quite some users, interested in the nice look & feel and not really in performance. So it's still relevant!

I will continue to follow your project and I wish you all the best for the bachelor thesis.

[ElSaico]

That's a very elucidating response.

I stumbled upon CTk as an option for the aging UI of Elite: Dangerous Market Connector, an application which has also over time fostered an active ecosystem around it - and, very importantly, changed maintainers more than once.
This could allow us to throw away hundreds of lines of cruft on both its very hacky dark mode implementation and the platform-specific stuff that CTk already handles, while remaining backwards compatible with existing plugins (which make any non-Tkinter solution a very last choice). Alas, as a Portuguese speaker I was immediately stopped by the canvas locale bug (#571), and proceeded with a pure Ttk solution.

However, progress has slowed to a crawl because of Tk shenanigans, so it might make sense to wait for a new release and try it out instead.
Being on the final stretch of a thesis is a more than understandable reason to not have time left for anything else, so let me just address a couple points:

I never could bring myself to the point of assigning collaborators because I thought, and still think, that this project is not suited very well for collaborative development. There are so many workarounds and hacks used to make this library work which I dont understand myself after some time.

The source code for any long-running piece of software can become a wild ride and a half, yet life goes on regardless.
EDMC is on its third (fourth?) maintainer - his predecessor remains around, but not the original creator, so HIC SVNT DRACONES on some places. And I dove straight into a UI overhaul of it, for crying out loud! 😆

And if one merges a pull request without being aware of these or without proper testing it could be that functionality breaks but only on certain operating systems and so on.

A fair concern, and one that EDMC constantly faces. One way to alleviate it could be by strengthening and automating its test suite, so that it runs on Actions - yes, it'd take significant work (and does it allow a practical way to do Selenium-esque functional testing for desktop apps?), but it pays off on stability and peace of mind.

The makeshift nature of this project is also what kept me from working further on the project because I saw no future for it because of all the workarounds and the disappointing performance.

Those are part and parcel for any Tkinter UI of a meaningful size, so why not concentrate improvements on a focal point instead of everyone needing to figure out a solution with a very high chance to turn out worse?

But as so many people are still using the library I might get motivated enough after my thesis to start addressing the most important bugs and feature requests. I will also think about assigning collaborators, at least for moderation. Only a little patience is needed until then. 🙏

Given the timeframe, my guess is that you're probably still decompressing from the thesis effort. Take your time, the community you fostered (with several libraries out there proudly announcing CTk support, a good indicator of success IMHO) will be here waiting.