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.