Index

log4qt的学习(V0.1)

今天正好和人聊着聊着记录qt的一些输出信息。正好就说到了log4qt。这个项目本来

loger()里面对函数的支持类型还比较少。希望以后可以再继续增加

如何截获qdebug()等信息? 软件里面是有介绍的。但是对于具体的实施。还有待继续研究。

20110516

其实每天写写日记神马的也没有什么不好的= =特别是在一个只能教育网才能访问的而且还关闭了搜索引擎的访问的自己的嘟噜博客上面= =真的是个很好的方式啊= =~
完全就是基本上一个人的随笔记录了啊= =

今天真是悲催的一天啊。。。

本着悲剧再次重演的想法又一次的重装了系统..在到底选择什么样的系统的问题上产生了很大的分歧...最开始选择的是才出来的ubuntu11.04...但是装好之后一直觉得unity界面那叫一个不爽啊...反正就是莫名的不爽...结果就走上了一条完完全全的不归路
..从最开始的选择.到后来的一直折腾..历经了一条很漫长很漫长很漫长很漫长很漫长的道路啊...
<!--more-->
最开始是准备安装的ubuntu1104.但是装好了之后unity界面确实看着很不爽...全局菜单也有时候很不好使....就想着开始自己安装gnome3.也就是传说中的gnome-shell.在1104里面可以添加一个源直接安装..看起来很简单的一个教程.的确安装也非常的快...装完了之后也嫩能够通过修改启动选项设置默认启动..但是...最关键的但是来了!!!任何的系统设置都不可以!!!没有网络图标!!!但是却能上网.....任何改动都点了没反应啊...
这不是坑爹啊!!!我装来就只能上网啊!!!靠!

好吧好吧..其实是有说法是现在的gnome-shell的源还不是很完善.也没有什么稳定的源.....但是感觉还是可以再等等.就目前来说,gnome-shell的效果和理念还是比unity要好一些的...期待再过个大半年,等1204什么的时候出来了再看看发展..

都这样说了.所以下面开始了opensuse的安装之路啊.....
开始是在opensuse和fedora之间选择.现在fedora15还是beta版本.opensuse11.4release也有点早了...
犹豫了半天还是选择了opensuse.(绝对不是因为我那天参加opensuse的release party之后得到了一张安装盘才选择它的!)
送的dvd32位的里面附带的东西真的很全...真的很全.比什么ubuntu的dvd版本东西多多了...里面可以很方便的定制想要的软件与程序.我真的觉得这点做得非常好啊...每一种桌面环境.每一个必要非必要的软甲包都可以随心所欲的自己选择= =~
比如我计划安装KDE桌面(也是opensuse默认的桌面环境).但是里面的每一个安装包都可以自由的选择..比如我的电脑肯定不会用到打印机.也不会用到蓝牙.所以我可以直接把基础的包里面的跟着两个相关的安装包全部的关掉.安装的时候就不会安装了..这点非常的给力啊...
再比如安装libreoffice的时候.我可以选择性的安装其中的几个必要的组件.他自带的一个libreoffice-Base.就是那个用来安装数据库支持的库我就完全没有安装的需要..所以也直接关闭就好了的...
在dvd里面也自带了很多有用的编程需要的套件啊....而且还很全...什么kdde的开发.qt的开发.perl,python的应有尽有啊...
在测试的时候想得很好.就是把需要或者觉得要用到的文件全部都选中了..然后他也很智能的把我自己新增的,又修改的地方的depending包全部列出来了.就相当于一个自动的依赖检查...很实用方便的一个东西.装东西本身没有什么太多的问题.时间也非常的短(再一次感谢我之前英明的选择了SSD作为折腾的硬盘啊.).
装好了opensuse之后又见到了熟悉而又陌生的kde桌面环境啊.比起当时运行kubuntu的时候,界面UI方面本身没有什么大的改动.但是新增了一些suse自己写的东西.比如自己的一个系统管理软件..用起来本身没有什么问题.预先弄好的IDE环境也都可以运行,没有什么问题的说.
但是总是有一种很不明的蛋疼.就好像一直有一股阴风一直吹在那儿一样.所以...
没用多久还是觉得放弃了..
后来又在几个网站很随意的浏览了一番.linuxmint的官网里面11还是RC状态,而且从下面的回复来看.貌似还有着很严重的问题.比如无法打开gnome-theme的主题.没有moonlight支持(虽然我用不到)等等的几个看来目前还比较严重的问题.所以在等待他的final版本出来之前我还是得再观望观望好了..
虽然也想尝试MACOS系统.但是发现木有现成的空的光盘(好牵强的理由啊).所以这个需求也不能满足啊.....而且网上各种说明,提到在x200上面装系统很容易就悲剧了...各种没有驱动什么的..唉~

最后还是本着不尝试就会死星人的本质思想。在lunixmint11的最终版出来之前。尝试了最新的windows8的开发版.....确实带来了不错的更新.目前的版本可现有的驱动之间结合得也还行.所以安装本身没有遇到什么大的问题.安装好了之后(也就是目前正在使用的).随便简单的装了最基本的软件.连防病毒软件都没有安装(从linux下面遗传下来的坏习惯啊.).其实对于现在的SSD.容量还是很小的.装好这种庞然大物之后真的没有剩下多少空间啊...装个QQ(邮件该死的QQ).再装个QT之后差不多其他空间真没剩多少的...哈哈...不过用着目前还没有什么大的问题....
不得不在最后吐槽一下:为神马这坑爹的美工啊!!!尝试吃螃蟹的大哥们你都伤不起啊!!!

[ZZ]关于QT5的讨论(二)

Responses to Qt 5


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.
<!--more-->

QML/JavaScript versus C++

There were a lot of reactions to the statement that we would like to make JavaScript a first class citizen for application development. What we are talking about here is adding another option, not removing C++. Qt is in its heart a C++ framework and this will not change. Quite to the opposite, I see C++ as continuing to be extremely important. There are many use cases where you need to be able to write native code.

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.

JavaScript fits in naturally here, as QML is syntactically an extension to JavaScript. Being able to write or prototype parts of your application logic in a scripted language makes many things easier. Remember that this is a choice Qt wants to offer, not a requirement.

As to those asking for other scripting languages: No, we don’t intend to integrate these into Qt or QML. There are many reasons for that, but the simple ones are that it would seriously complicate the Qt Quick architecture and it could slow us down. It’s better to do one language and do it really well than to have something that will in the longer term become unmanageable. Having one consistent offering for developers is also very important here. Multiple scripting languages would just be confusing. JavaScript was chosen, because there are extremely high performant engines out there, because the basics of the language are very similar to what our developer base is used to from C++, and because it has the widest user base of all scripting languages out there.

QWidget and QGraphicsView

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.

Requiring OpenGL

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.

Other things

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.

[ZZ]关于QT5的讨论(一)

Thoughts about Qt 5


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.
<!--more-->

Objectives with next major version of Qt (Qt 5)

  • Make better use of the GPU, allowing you to create smooth (and accelerated) graphics performance even with limited resources;
  • Making your creation of advanced applications and UIs easier and faster (with QML and Javascript);
  • Make apps connected to the web be as powerful as possible, i.e. to embed and power up web content and services into any Qt app; and
  • Reduce the complexity and amount of code required to maintain and implement a port.

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.

Making it straightforward to move applications from Qt 4 to Qt 5

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.

Developed in the open, together with you, with strong backing from Nokia

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.

Vision

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.

We should expect that over time all UIs will be written in QML. JavaScript will become a first class citizen within the Qt community and we should expect that a lot of application logic and even entire applications will be written in JavaScript instead of C++. The expectation is that many application developers will actually start out with QML and JavaScript and only implement functionality in C++ when required. For those specific use cases, the full power of the C++ APIs offered by Qt can be used to implement time critical and complex application functionality.

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.

Four big architectural changes:

  1. Re-architecture our graphics stack
    We will put Qt Quick and the QML Scenegraph into the center of our new graphics architecture. QPainter will still be available and is very useful for many things, but it won’t be used for the main user interface. Qt will require OpenGL (ES) 2.0 to work. QWidgets will be layered on top of the scene graph (not the scene graph on top of QWidgets as is currently done with Qt 4).
  2. Base all Qt ports on Lighthouse
    The Lighthouse project was started with the goal of providing a better way to abstract the window system integration than we currently are using. It’s now reaching maturity with Qt 4.8, and we intend on using it exclusively for all Qt ports in Qt 5.0.
  3. Modular repository structure
    A lot of this work has been done over the last weeks and you can see the results in the new modular Qt repositories. The modularization of Qt will facilitate and speed up the possibility to integrate contributions to Qt.
  4. Separate all QWidget related functionality into its own library
    While the QWidget based classes are extremely important for existing applications, we are, over time, going to move to a model where all UIs are being done in QML. Separating the QWidget based functionality into its own library is therefore a good measure to achieve a clean architecture in Qt 5 in the long term.

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.

Beta quality code available towards the end of 2011. Final release in 2012

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.

Help us speed up the development

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.

AQP学习笔记(一)

Chapter 1: Hybrid Desktop/Internet Applications

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.
总的来说呢,就是这个QCache类可以自动管理里面的数据.切删除放不下的chache的时候回首先从最少使用的那些数据开始删除...很自动化的一个东西.

今天花了点时间看完了第一章.找个时间一起总结一下
这几天花了大量的时间看完了前几章..真的写得不错..但是隐隐约约感觉有点问题...唉~





github..哎..还是可以用的~

git://github.com/zzjin/CoopES.git
折腾了半天(真的是半天啊!)弄了个目前项目的git.欢迎围观啊~
话说git不愧是linus写的东西啊= =在linux下面可是大放异彩啊...
虽然很想吐嘈连git源代码本身都是由git来管理的....但是很多诸如linux内核啊= =
qsanguosha什么的软件都使用的是git进行管理.
目前比较常用的两个git托管服务商就是github与gitorious了.都提供了较好的托管服务.也有非常友好的用户前台界面..出了两个都是国外的服务器导致回时不时的连接超时之外.真的都很方便.

尘埃落定的前兆?

周五的时候和姚老师好好的谈了谈
不知不觉五一长假又过去两天了.但是还是什么都没有弄啊!!!
现在的压力仍然很大..期待能加快速度啊TT
周末的晚上.五月一日的晚上.
虽然很想说"就这样吧",但是还是有着不见少的任务啊

.今天接到个电话.

RT.看来信安还是有希望的?
不.其实还真不行...还是各种坑啊= =