3 ms·
None of this is an argument in favor of a fork. Even if what you write were true (and that hasn't been my impression), somebody would still have to do the work
by nhaehnle 11y ago
None of this is an argument in favor of a fork. Even if what you write were true (and that hasn't been my impression), somebody would still have to do the work of improving QtWidgets even further. They might as well do that work in Qt itself without producing a fork.
It's obvious judging from other comments in this thread that Qt has some problems making people unhappy. However, where those problems are genuine, the author's energy would be better spent to fix those inside Qt rather than creating a new project/fork. (If the goal is actually to help other developers; of course, if all the author wanted was to create an interesting proof of concept, then more power to them.)
- deleted 11y ago[deleted]
- 0xFFC 11y agono fence , but do you understand what he/she talking about ? Qt (simply) does not allow any changes to Qtwidget code base's . (If I remember correctly) they even freezed Qtwidget API.
- nhaehnle 11y agoWhat on earth are you talking about? Take a look at the repository mirror here, for example: https://github.com/qtproject/qtbase/ https://github.com/qtproject/qtbase/. You can easily see plenty of commits that change src/widgets. Seriously, please point to where you get these ideas from, because they're just extremely odd and surprising, seemingly coming out of nowhere as if somebody were spreading FUD. (One theory that I have is that there may be confusion about the API and ABI compatibility guarantees that Qt makes. If you're not used to the C++ way of doing things, it's easy to misunderstand their policy. I assure you that there are no artificial limitations to changes in Qt, and if you have concrete grievances with something you should try and get it fixed inside Qt just as with any other open source project.)