5 ms·

Downvoter, care to explain? This information is 100% correct.

mdda 13y ago
(I didn't downvote, but) : (0) Reread the first sentence; (1) Dismal tone; (2) Its; (3) Downvote complaint inaccurate in that it ignores (0).
- general_failure 13y ago
  Sorry, all that was just a typing mistake. Fixed. Thanks for pointing it out.
ihsw 13y ago
I believe you meant to say "Qt5 or Qt4" instead of "Qt5 or Qt5." Please correct me if I'm wrong.
emilsedgh 13y ago
QtWidgets are marked as 'Done' it Qt's module list, which means its maintained but no new features are added. However, since this module has been under heavy use in the past, its feature complete and needs no new features. Its still used by hundreds of legacy applications and is in no way 'obsolete'. [0]http://qt-project.org/wiki/Qt_Modules_Maturity_Level http://qt-project.org/wiki/Qt_Modules_Maturity_Level
- general_failure 13y ago
  OK, so we agree that: 1. It won't have new features since it's feature complete. 2. Nothing will basically change. 3. All new development of Qt project is done in QML. 4. New features will be added in QML only. So, if some cool widget comes along in a new OS version, you don't have it Widgets anymore. For me, it's all but obsolete. If you want to argue about English usage, then that's fine.
  - dvratil 13y ago
    1) It can have new features - the are some upstreamed from KDE, and it's just about users coming with new proposals - nobody cames, no new features. Easy. 2) Why would you change something that needs no changing? 3) Lot of efort goes to QML, yes. Why not? 4) Maybe. Nothing prevents you from writing QWidget equivalent of the "cool" QML widget and upstreaming it. Obsolete stuff is unmaintained. You can rest assured that QWidgets will be maintained and bugs will be fixed.
sho_hn 13y ago
No, this information is hardly "100% correct". Here's what's actually going on: (1) During the 4.x cycle, Qt integrated a new declarative markup language called QML, as part of a new language + batteries module called Qt Quick. In Qt 5, Qt Quick has improved significantly and become a very viable choice for many interesting and useful applications. (2) Desktop-type applications are not yet among those. While Qt 5.2, to be released toward the end of this year (currently it's in alpha) contains some new Qt Quick batteries to implement desktop-type interfaces that are quite promising, they're also still fairly young and rough, and not suitable for demanding applications. (3) QWidget continues to be maintained and fully supported. It's mature technology that hasn't seen massive changes in the initial leap to Qt 5, but has nonetheless benefitted from many improvements in the core of Qt. (4) Further, in Qt 5.2, the KDE community in particular (which is in the process of transitioning to Qt 5 and is a major stakeholder of QWidget, while also making strong and increasing use of Qt Quick) has upstreamed tons and tons of features and code that make QWidget and related APIs even stronger than it already was. Qt 5.2 is an exciting release for users of QWidget and QML alike. (5) Qt is a proper open source project with well-working governance today. It's also a well-modularized, well-layered codebase. There are no significant roadblocks to caring for and maintaining QWidget for as long as the Qt community sees fit. At the same time, Qt Quick offers some compelling advantages and is likely to evolve as well.
- sandGorgon 13y ago
  We are building a small desktop app (to complement a hardware device) using Pyside (or PyQt). Would you say that is a risk ? Do you recommend a different way to go about it with sufficient productivity as Python ?
  - sho_hn 13y ago
    I don't see any significant risk there. QWidget has many large commercial as well as FOSS deployments that will see it stick around for many years to come, and Riverbank's PyQt Python bindings are likewise used by many large commercial and FOSS offerings, and very actively maintained, tracking upstream Qt quite closely. I've written some PyQt apps as well (alongside lots of C++ and Qt Quick) and I think it's a very nice way to use the toolkit (in fact I'm relieved C++11 added some of the things that made using PyQt so nice). I've been a KDE developer for the last 8 years, and in that time I've seen Qt steadily improve as an open source project. When I started out using Qt, getting code into it was essentially impossible without becoming a Trolltech employee. Today it's quite open to its various stakeholders, who manage to collaborate constructively. My confidence in Qt's resilience has increased with our level of agency in making that resilience happen.

mdda 13y ago

(I didn't downvote, but) : (0) Reread the first sentence; (1) Dismal tone; (2) Its; (3) Downvote complaint inaccurate in that it ignores (0).

general_failure 13y ago
Sorry, all that was just a typing mistake. Fixed. Thanks for pointing it out.

ihsw 13y ago

I believe you meant to say "Qt5 or Qt4" instead of "Qt5 or Qt5." Please correct me if I'm wrong.

emilsedgh 13y ago

QtWidgets are marked as 'Done' it Qt's module list, which means its maintained but no new features are added. However, since this module has been under heavy use in the past, its feature complete and needs no new features. Its still used by hundreds of legacy applications and is in no way 'obsolete'. [0]http://qt-project.org/wiki/Qt_Modules_Maturity_Level http://qt-project.org/wiki/Qt_Modules_Maturity_Level

general_failure 13y ago
OK, so we agree that: 1. It won't have new features since it's feature complete. 2. Nothing will basically change. 3. All new development of Qt project is done in QML. 4. New features will be added in QML only. So, if some cool widget comes along in a new OS version, you don't have it Widgets anymore. For me, it's all but obsolete. If you want to argue about English usage, then that's fine.
- dvratil 13y ago
  1) It can have new features - the are some upstreamed from KDE, and it's just about users coming with new proposals - nobody cames, no new features. Easy. 2) Why would you change something that needs no changing? 3) Lot of efort goes to QML, yes. Why not? 4) Maybe. Nothing prevents you from writing QWidget equivalent of the "cool" QML widget and upstreaming it. Obsolete stuff is unmaintained. You can rest assured that QWidgets will be maintained and bugs will be fixed.

sho_hn 13y ago

No, this information is hardly "100% correct". Here's what's actually going on: (1) During the 4.x cycle, Qt integrated a new declarative markup language called QML, as part of a new language + batteries module called Qt Quick. In Qt 5, Qt Quick has improved significantly and become a very viable choice for many interesting and useful applications. (2) Desktop-type applications are not yet among those. While Qt 5.2, to be released toward the end of this year (currently it's in alpha) contains some new Qt Quick batteries to implement desktop-type interfaces that are quite promising, they're also still fairly young and rough, and not suitable for demanding applications. (3) QWidget continues to be maintained and fully supported. It's mature technology that hasn't seen massive changes in the initial leap to Qt 5, but has nonetheless benefitted from many improvements in the core of Qt. (4) Further, in Qt 5.2, the KDE community in particular (which is in the process of transitioning to Qt 5 and is a major stakeholder of QWidget, while also making strong and increasing use of Qt Quick) has upstreamed tons and tons of features and code that make QWidget and related APIs even stronger than it already was. Qt 5.2 is an exciting release for users of QWidget and QML alike. (5) Qt is a proper open source project with well-working governance today. It's also a well-modularized, well-layered codebase. There are no significant roadblocks to caring for and maintaining QWidget for as long as the Qt community sees fit. At the same time, Qt Quick offers some compelling advantages and is likely to evolve as well.

sandGorgon 13y ago
We are building a small desktop app (to complement a hardware device) using Pyside (or PyQt). Would you say that is a risk ? Do you recommend a different way to go about it with sufficient productivity as Python ?
- sho_hn 13y ago
  I don't see any significant risk there. QWidget has many large commercial as well as FOSS deployments that will see it stick around for many years to come, and Riverbank's PyQt Python bindings are likewise used by many large commercial and FOSS offerings, and very actively maintained, tracking upstream Qt quite closely. I've written some PyQt apps as well (alongside lots of C++ and Qt Quick) and I think it's a very nice way to use the toolkit (in fact I'm relieved C++11 added some of the things that made using PyQt so nice). I've been a KDE developer for the last 8 years, and in that time I've seen Qt steadily improve as an open source project. When I started out using Qt, getting code into it was essentially impossible without becoming a Trolltech employee. Today it's quite open to its various stakeholders, who manage to collaborate constructively. My confidence in Qt's resilience has increased with our level of agency in making that resilience happen.