Inside QT series (13): Overview of QT/ebody Structure

Source: Internet
Author: User

In the subsequent content, I will not explain this term in QT for Embedded Linux for short. Note that, in any part of this series of articles, This term refers to QT for Embedded Linux, not QT for Windows CE or QT for Symbian.

The applicable software versions are QT for Embedded Linux 4.6 and open source edition.

First, let's take a look at the system structure of QT/E:

The biggest difference between QT for destop Linux and QT for Embedded Linux is that they depend on different underlying display bases, which leads to their architectural differences. For QT for Desktop Linux, the underlying display technology is built on X Window System and relies entirely on X system, at the lower layer, they call the system method of X lib to display the interface.

Qt for embedd Linux is completely different in this regard. It is not built on X Window, but on the Framework buffer of Linux, the content to be displayed on the interface is directly written into framebuffer. Because the X system is omitted in the embedded system, this will save a lot of system overhead. Directly Writing framebuffer will speed up the display. This difference:

However, this change has resulted in an additional server layer in QT/E, which monitors system events, especially keyboard and mouse events, screen outputs, and manages region, manage top-level windows, manage cursors, screen saver, and more. The keyboard and mouse events generated by the system are first transmitted to the server application, and then the server distributes these events to the corresponding applications according to the specific situation.

Every QT/e application requires such a server. After a program runs, if it becomes a server process, it is connected to an existing server process. Therefore, the first running QT/e application will start the server to make itself the server process, and subsequent running programs will be connected to the server to manage themselves.

On the server side, each client connected to the qwsserver has a qwsclient object that records the Client ID. Each time a top-level window is created in the application, a qwswindow instance is created on the server side to correspond to it.

Whenever the server receives an event, it needs to determine the window to which it should be sent. At this time, it will find it from the qwswindow list, then, find the corresponding client application according to the window, use a qwsevent object to wrap this event, and send it to the specific client application through the socket mechanism. If an input method is installed in the current system, the corresponding method of the input method is called every time a keyboard event is generated. (From the QTE document ):


 

The processing of mouse events and Keyboard Events also comply with the above process. The mouse driver is encapsulated by a qwsmousehandler object, and the keyboard driver is encapsulated by a qwskeyboardhandler. Both driver objects are loaded through the QT plugin mechanism. After a specific mouse or keyboard event occurs, it is encapsulated into a qwsevent object and sent to a specific client. (From the QTE document ):

 


 

For graphical output, the default QTE behavior is that each widget will draw itself into a piece of memory, and then the server is responsible for copying the fast memory to the framebuffer of Linux (from the QTE document ):


 

However, for most embedded systems, the display subsystem is definite, so that the client application can directly output it to framebuffer. There are two ways to achieve this. The first is to set the QT: wa_paintonscreen attribute for each widget, and the other is qdirectpainter to retain a region in framebuffer, (From the QTE document ):

========================================================== ====================================
Statement:
Inside QT series is an original technical article (http://www.qkevin.com.
This series of columns can be reproduced at will, but the statement and original address of each article must be kept.
The Copyright reserved by the author shall not be used for any commercial purposes without the consent of the author

Total index of the column in inside QT series: http://www.qkevin.com/qt
Original address: http://www.qkevin.com/archives/98

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.