3 ms·
To be perfectly honest a fork in Qt does not surprise me. Most of the people I know who are using Qt use the QWidgets api which has been neglected since 4.8 . I
by dman 11y ago
To be perfectly honest a fork in Qt does not surprise me. Most of the people I know who are using Qt use the QWidgets api which has been neglected since 4.8 . Increasingly Qt development appears to be geared for completely new paradigms (Mobile, Scene graphs, Styling via CSS, QML, QtQuick ...) while leaving the core desktop functionality at a stand still.
- nib952051 11y agoDont be surprised but development of widgets/core libraries wasn't stopped, just fetch qtbase and inspect git logs. Keep in mind that there is QtCreator which based on QtWidgets and unlikelly will be based on something else. What kind of styling, qss? What new widget class do you need?
- weland 11y agoThe QWidgets API seemed to work just fine the last time I touched it. I'm not unhappy. I see no reason for a fork. And I've never used QML, QtQuick and all that. I played with them a little, saw absolutely no point in it, and never really needed them. But the QWidgets API is nice, stable and very well documented.
- dman 11y agoMany serious desktop bugs remain unfixed. Perhaps if there was less of a stress on new features, there would be more bandwidth to fixing existing bugs. Here is an example bug - drag and drop with filenames is broken out of the box on Yosemite and has been for quite a while - https://bugreports.qt.io/browse/QTBUG-40449 https://bugreports.qt.io/browse/QTBUG-40449 . Also you just have to go take a look at the comments in the Qt release announcements to see that the views I am expressing here are not an isolated case. Here is an example - https://blog.qt.io/blog/2015/03/17/qt-5-5-alpha-available/#comment-1195322 https://blog.qt.io/blog/2015/03/17/qt-5-5-alpha-available/#c...
- weland 11y agoFair enough; I was under the impression that the situation was far less serious.
- nhaehnle 11y agoNone 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.)