Weekly Edition
Return to the Development page
| |||||||||||||
Qt5 Alpha released
The first alpha
release of the Qt5 toolkit is available, showing the direction that Qt
is taking. A lot of the work appears to be under-the-hood restructuring,
but there's a number of new features as well. "There was one basic vision driving a lot of the Qt 5 work:
'Qt 5 should be the foundation for a new way of developing
applications. While offering all of the power of native Qt using C++, the
focus should shift to a model, where C++ is mainly used to implement
modular backend functionality for Qt Quick.'" (Thanks to Paul Wise).
(Log in to post comments)
Qt5 Alpha released Posted Apr 4, 2012 17:23 UTC (Wed) by dashesy (subscriber, #74652) [Link]
Qt is a great piece of software, I am grateful that Qt Widgets will still be supported for traditional desktop. And the fact that is will provide the backbone, means that it will only get better.
Qt5 Alpha released Posted Apr 4, 2012 18:24 UTC (Wed) by josh (subscriber, #17465) [Link]
One interesting development: Qt 5 has now moved to XCB for platforms using X, and has dropped the Xlib backend entirely.
Qt5 Alpha released Posted Apr 4, 2012 22:02 UTC (Wed) by tao (subscriber, #17563) [Link]
Good riddance!
Qt5 Alpha released Posted Apr 8, 2012 3:34 UTC (Sun) by elanthis (guest, #6227) [Link]
Is there a sane GLX-over-XCB story yet? Last time I looked, it appeared you needed to keep xlib just to get the GLX stuff, since XCB refused to implement the GLX protocols natively (claiming that Khronos was in charge of the APIs, as if they actually owned the right to create new ones).
Qt5 Alpha released Posted Apr 8, 2012 4:28 UTC (Sun) by josh (subscriber, #17465) [Link]
I don't know where you got the idea that XCB refuses to implement GLX. XCB just needs a couple of technical enhancements so that it can handle the GLX protocol. In particular, the libraries built on top of GLX need the ability to process a GLX-related event invisibly without it reaching the application's event loop (because the application won't know what to do with it, and compatibility with the GL and GLX APIs requires that the application not have to know what to do with it). XCB currently doesn't support a side-channel event like that, but as of recently, we have a plan to fix it.
Qt5 Alpha released Posted Apr 5, 2012 17:13 UTC (Thu) by slashdot (guest, #22014) [Link]
Any progress in not reinventing the wheel/standard C++ library with idiotic things like QString, QPair, QVector, QList, etc.?
Generally this kind of thing is a sure sign that a C++ library is total crap.
Qt5 Alpha released Posted Apr 5, 2012 17:17 UTC (Thu) by slashdot (guest, #22014) [Link]
Oh, they require OpenGL, ouch.
This is a sure-fire way to make a GUI library unusable for general-purpose apps.
Qt5 Alpha released Posted Apr 5, 2012 19:14 UTC (Thu) by krake (subscriber, #55996) [Link]
It does not require OpenGL for standard widget based UI.
Qt5 Alpha released Posted Apr 5, 2012 17:35 UTC (Thu) by khim (subscriber, #9252) [Link] Generally this kind of thing is a sure sign that a C++ library is total crap. Generally this kind of comments means the commenter is an idiot. Most old C++ libraries include things like that because C++ compiler predate STL by many years. Not all of them are crap.
Qt5 Alpha released Posted Apr 5, 2012 21:28 UTC (Thu) by przemoc (subscriber, #67594) [Link]
> > Generally this kind of thing is a sure sign that a C++ library is total crap.
> > Generally this kind of comments means the commenter is an idiot. Most old C++ libraries include things like that because C++ compiler predate STL by many years. Not all of them are crap.
No good reason to go ad hominem, khim. Generally all generalizations are bad, it's truism.
slashdot went a bit overboard here too, that's for sure. Yet it's not only about libraries created before STL or standard library. Qt4 doesn't predate them. But it's not a problem. The problem, or rather just a fair notice, is that standard library and STL together, in all their glory, aren't the one and only libraries that solves all our problems. And even if they solve them (well, definitely more in C++11 than before), it's not always in a way we'd want it to be done.
[ slashdot, indirect point about using bloated yet lacking in features std::string (std::basic_string) for instance, all the time, just because it's already there in the standard is moot at best, really. ]
Qt5 Alpha released Posted Apr 7, 2012 11:37 UTC (Sat) by robert_s (subscriber, #42402) [Link]
You should perhaps look at those classes before making dumb comments.
QString & friends are actually really good and one of the nicest things about coding an app in Qt is being shielded from the madness of much of the STL by nicely-integrated utility classes.
It's so convenient people often write console-only apps in Qt (which, no, _won't_ depend on OpenGL or any other nonsense you can come up with).
Qt5 Alpha released Posted Apr 7, 2012 16:08 UTC (Sat) by rqosa (subscriber, #24136) [Link] QString at least has a good reason to exist — it's a natively-Unicode string class capable of converting its internal representation to/from multiple different byte-stream encodings. As for the template-containers like QMap, QList, etc., though, I don't really see a good reason for keeping them, other than that forcing a migration to STL would likely require lots of programmer effort (for both Qt itself and Qt-using software).
Qt5 Alpha released Posted Apr 7, 2012 17:08 UTC (Sat) by dark (subscriber, #8483) [Link] QMap and QList have the nice copy-on-write semantics that are common in Qt's core classes. Replacing them with STL templates would mean giving that up, and it would mean complicated interface changes to functions that currently return QMap or QList values. The STL templates would be awkward strangers in Qt's memory management idioms. I don't see any benefit in such a change.
|
|||||||||||||