Linked by Thom Holwerda on Mon 9th Apr 2012 11:03 UTC
Qt "The Qt development toolkit is undergoing a major overhaul. The developers behind the project announced the availability of the Qt 5 alpha release this week. It's a key milestone on the path to the official launch of Qt 5, expected to occur later this year." The kind of stuff to read Ars for.
Thread beginning with comment 513477
To view parent comment, click here.
To read all comments associated with this story, please click here.
anda_skoa
Member since:
2005-07-07

I wonder how badly the KDE project will be hit once Qt starts to mandate the use of OpenGL.


This is a academic question since Qt does not nor will it in the forseeable future do that.

Since you are posting this as a comment to the Qt5 alpha announcement, I guess you might have misintereted the part of QtQuick2 now using an OpenGL/ES bases screen graph.

QtQuick2 is new in Qt5 and can therefore have update requirements, however everything that is in Qt4, e.g. normal widget based GUI, still has its present requirements.

The X11 platform plugin, for example, implements those parts via XCB, i.e. standard X11 capabilities.

Reply Parent Score: 2

Neolander Member since:
2010-03-08

But as far as I know, the Qt teams have pretty much stated that they are not interested in developing the QWidget part of Qt any further.

So for KDE, it will either be switch to QtQuick, or stick with a portion of Qt that is deprecated without saying it.

Reply Parent Score: 1

anda_skoa Member since:
2005-07-07

But as far as I know, the Qt teams have pretty much stated that they are not interested in developing the QWidget part of Qt any further.


There are two things to that:
1) If Nokia doesn't see any need to put resources into adding new things to the widgets library of Qt does not keep others from doing so. This is already happing with support for certain platforms (e.g. WinCE), so it is IMHO likely to expand to other areas.

2) Not adding new things doesn't equal deprecating. The widgets library as it is continues to be useful for standard desktop applications as all features needed for those are already there.


So for KDE, it will either be switch to QtQuick, or stick with a portion of Qt that is deprecated without saying it.


KDE, and any other vendor using Qt, will use whatever is most appropriate for a given context.

Some products, e.g. KDE's workspace shell, are already using a non-widget approach and will most likely switch to QtQuick.

Other products, e.g. Qt Creator, will surely continue to use a widget based UI.

And some products will use a QtQuick based UI in their mobile version while continuing to use a widget based one for the desktop version.

I personally expect most current Qt software producers to stick with a widget based approach and QtQUick mainly be used by companies starting product development for non-desktop applications

Reply Parent Score: 2