其实每天写写日记神马的也没有什么不好的= =特别是在一个只能教育网才能访问的而且还关闭了搜索引擎的访问的自己的嘟噜博客上面= =真的是个很好的方式啊= =~
It’s great to see so much feedback coming in about my Qt 5 blog two days ago. We’ve read and gone through all the comments, but it’s easier to try to answer the questions and concerns in a follow-up post rather than replying to comments.
We have now created a mailing list for discussions about Qt 5. If you’re interested, please consider subscribing. This will allow us to have better and more structured discussions around Qt 5 than replies to a blog post.
As far as I can see the main concerns can be grouped into a few categories. I’ll try to answer these from my point of view.
So we will continue to add new C++ APIs and improve our existing C++ APIs to give you all the power and options one expects from a native framework. On the non graphical side (ie. QtCore, Network, database, etc.) nothing really changes, and on the graphical side we for now simply add another option.
That being said, we do believe that Qt Quick is the better technology for creating user interfaces. Right now, it still misses some things that developers (esp. on desktops) need. But once we combine what e.g. ListView with the desktop components Jens has been prototyping we do have a pretty good offering for many desktop use cases. But the goal is certainly to improve this over time and we believe this will make everybody’s life easier in creating compelling, modern looking applications.
The QWidget-based classes will not suddenly disappear. Neither will they suddenly stop working. The exact goal with moving them into a separate module is to ensure our efforts on Qt Quick/QML will not cause problems for these classes. We ourselves intend on continuing to use them in Qt Creator and other applications for the foreseeable future.
We also don’t believe there will be bigger performance problems using these classes once we have re-architected the graphics stack in Qt. They might even become a bit faster on some of the platforms (but that’s a subject for a post of its own). Remote X11 connections is a use case that might get a slight hit. However, the trend in the industry has been moving away from X11 anyway. If there’s a strong interest by a group of people to support this use case, there is an opening to pick this work up and integrate with technologies such as NX. With the Lighthouse architecture, this might be just one plug-in away.
Together this means that there is no need for you to start worrying about having to rewrite the UI of your application in Qt Quick. But again, we believe strongly that it will in the longer term become the better and easier option compared to QWidgets.
As stated in the post we will require OpenGL 2.0 support for Qt 5 (Desktop GL or GL ES). The reason is simply that this gives a much better common ground for application developers. It also helps to significantly simplify our internal architecture.
We went through all the same concerns that I saw in responses to the blog post about having it as a requirement. In the end we came to the conclusion that it would be the best path forward and should not pose a real problem to most of our users.
On Mac and Windows this should not cause any real problems. Mac OS X has good OpenGL support on all their devices. On Windows we can use the ANGLE library to translate OpenGL ES to DirectX if it turns out that there are issues with native GL support.
On Linux desktops the recurring problem is the quality of some of the drivers. This is unfortunately a bit outside of our scope to get solved. But there is an alternative being worked on by the community that can be as good (or better) than our current Software rasterization: Mesa with llvmpipe. Having GL available consistently on Linux would be a tremendous improvement to the whole Linux stack.
The last part is low end hardware/embedded systems without a GPU. We are seeing that these systems are going away fast and that the price different between SoC’s with and without GPU is becoming very small. Given the great advantages a GPU offers to the achievable user experience and the fallback option to software GL outlined above, we believe it’s better to bet on OpenGL here as well.
We’re looking into some of the other features that have been asked for (like better C++11 support), but please remember that Qt 5.0 is not the end of the line and we will have 5.x releases where many of these improvements can then come in.
For 5.0 we have to carefully limit the scope of what we do. We will be working hard to not break anything that doesn’t need to be broken, and we’ll also be working to get 5.0 out in a timely manner.
Qt 4.0 was released in June 2005, almost six years ago. A lot has changed in the software industry over these years. While application development back then happened mostly on desktop systems, mobile devices connected to the web have become increasingly popular. User interface technology has moved from static widgets to a fluid touch based experience. Since Qt 4.0 we have released seven minor versions of Qt to stay ahead of development needs, for example by releasing Qt Quick. Within the growing Qt user base, we have had a strong up-take and new needs from embedded and mobile app and UI developers.
To also, in the future, be a leading edge development framework across multiple industries, Qt needs to continue to renew itself. Qt 4 has been an evolution, and I have been thinking about what future Qt versions might look like from a technical perspective. Over the last years we have been working on laying the foundations for the next major release. I see Qt Quick, QML Scenegraph and Project Lighthouse– combined with an increased focus on Qt Webkit – as the foundation which we plan to use to move towards a new major release of Qt.
Given that Qt is moving into open governance mode in the upcoming months, I wanted to share my thinking with the Qt community in order to kick off the discussions about what I see as the technical architecture for Qt 5.
Qt 4.7 contains some legacy code that prevents us from making Qt as good as possible for creating next generation applications and UIs. While most parts are still very relevant to our developer base, some parts are also blocking our way in the 4.x frame.
With Qt 5 we plan to make selected changes in the APIs and leave behind limitations from the past where required for the best of the future. For those of you that were with us for the transition of Qt 3 to Qt 4, we do not plan to repeat that difficult transition with Qt 5. To be explicit here – we believe we can keep source compatibility for the majority of cases, but we believe that breaking binary compatibility is needed. We will do everything to avoid breaking any fundamentals and to make it easy and very straightforward for the wide majority of applications to move from Qt 4 to Qt 5.
The initial thinking is that Qt 5 will focus on a small set of operating systems/platforms (i.e. platforms Wayland and X11 on Linux, Mac and Windows). The total number of platforms will depend on the community efforts invested as Qt moves into open governance mode. Other operating systems currently supported by Qt 4 (esp. commercial UNIX systems) will not be in focus for Nokia. The goal of the Qt 5 project is to offer the best possible functionality on each platform, implying that Qt will begin to offer more differentiated functionality on some OS’s, while still offering efficient re-use for the absolute majority of the code across platforms.
Another major change with Qt 5 will be in the development model. Qt 4 was mainly developed in-house in Trolltech and Nokia and the results were published to the developer community. Qt 5 we plan to develop in the open, as an open source project from the very start. There will not be any differences between developers working on Qt from inside Nokia or contributors from the outside.
If you want to involve yourself or your company in Qt 5 development, please join the Qt contributor summit in Berlin, June 16-18. This is the main place where we would like to discuss the plans and ideas we have for Qt 5.0 and 5.1 together with you. Some of us will also be at the Ubuntu developer summit this week and the MeeGo conference later this month.
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.
With Qt 5 we should put Qt Quick into the center of Qt without being disruptive for existing code developed for Qt 4. It will rather be a restructuring that will allow us to change the way we will think about application development in the future.
While traditional Qt/C++ applications will continue to work with Qt 5, there will be some fundamental changes on how applications can and will be written.
While we propose keeping the QWidget based programming model and API set available for compatibility, long term we also see QML as the future for user interfaces on the desktop. The solution here will most likely be QML-based component sets that integrate with the native styling APIs on the desktop platforms.
As you have seen from previous blog posts, the first three points have been worked on for quite some time and we’re starting the work on the last one right now. We do expect to have most of these changes done before August.
Qt Components and Qt Mobility will become more integral parts of the Qt platform and not be modules with a special status anymore.
Since we don’t believe we should change too many of Qt’s fundamentals, and the fact that we want to make it easy for existing applications to move to Qt 5 require us to be careful with the amount of changes we do to our existing code base. Many of the changes we are proposing and have started working on are about restructuring our code base into a new modular structure where every shared library lives in its own repository. We believe we should remove a few very rarely used APIs where keeping compatibility would block our way into the future. We think we will have beta quality code available towards the end of the year and final Qt 5.0 release some time during 2012.
Last week’s released Qt SDK with updates are planned to be used for the coming year to target Nokia Symbian and MeeGo devices. Qt 5.0 is focused around next generation application and UI development while still making it easy for apps developed with the Qt SDK to move to Qt 5.
For those of you interested in some more details, here’s a link to a whitepaper describing some of the ideas in more detail. None of it is set in stone, but it reflects our current thinking.
You can also follow our work in the set of modular Qt repositories. We intend on keeping the master branch usable at all times on at least Linux with both Wayland and X11 (xcb lighthouse plugin). Work on getting things up and running on Mac and Windows has started, but it’ll probably take a little while before these ports become usable again.
We are all extremely excited about doing this renewal of Qt together with you. We believe that some features will not be fully in place in Qt 5.0 and will only come over time in subsequent releases, but we believe it will be possible to not have any significant feature regressions to Qt 4.8 (yes, we intend to release one more minor version in the Qt 4.x series within the next couple of months!). While developing Qt 5 we must do our very best to maintain source compatibility with Qt 4, so that moving your application over to Qt 5 will be as simple as possible. So if you want to help out or get involved yourself in Qt 5 development, why not meet up with us at the coming to the Qt Contributors Summit in Berlin this June.
With a implement of a weather app to introduce it.
within it,I see a template class "QCache".
In fact it use the qHash to store data and afford quick search. In the Qt4.7.2's doc It says:
The advantage of using QCache over some other key-based data structure (such as QMap or QHash) is that QCache automatically takes ownership of the objects that are inserted into the cache and deletes them to make room for new objects, if necessary. When inserting an object into the cache, you can specify a cost, which should bear some approximate relationship to the amount of memory taken by the object. When the sum of all objects' costs (totalCost()) exceeds the cache's limit (maxCost()), QCache starts deleting objects in the cache to keep under the limit, starting with less recently accessed objects.