UI framework and Application

I should have written this article for a long time, because it was originally written to reply to wenzhezujie
. However, writing an article requires both time and mentality, and the result is delayed for a few days. It's not enough, but at least it should have started.

 

Copy the message for reference. -- "widgets and scheme/skin based on GTK should belong to the application level. It cannot be considered as the level of the UI framework. For example, in QT, the metadata system and the signal slot implementation mechanism are the core of the UI framework.
I don't think the kernel is designed at a higher level than the UI. For example, for Linux, the kernel has a process scheduling mechanism, and the underlying UI has the XWindow protocol. It can only be seen as a whole set of knowledge system structures. Independent modules such as kernel Windows System Network"

 

Let's talk about the software framework. In the ancient era of computer science, when people were still dealing with computers with paper cards, there was no framework concept. programs were all disposable, and computers were just used to repeat a task. After that, people naturally began to try to increase labor productivity, that is, they wanted to repeat what they had written, so the concept of routines and functions was added, however, these issues are not fundamentally resolved. Scientists began to try to solve it theoretically, and building, as a mature, industrialized technology, is widely used in computer software research. Simply put, just how to make writing software the same as building a house, and building several modules is almost the same, instead of always burning from one brick. This is why the System Architect is actually an Architect (Architect). Therefore, the initial framework is similar to the basic architecture of the House, which refers to the basic structure of the Software. (For details, refer to a large number of software engineering and object-oriented "great ideas ", the English version is recommended ). No matter whether it is reasonable or not, it is almost a conventional habit.

 

I think another purpose of the software framework is to solve or improve the problem of code reuse. In this regard, the software has its own unique place. Taking the layered structure as an example, we can define layers and interfaces very finely. The following layers can be called the upper layer framework, because theoretically, the upper-layer modules do not need to solve the problems solved by the lower-layer framework. That is to say, the corresponding code should only appear in the lower-layer framework and can be reused by different upper-layer modules through the same interface, this requires that the implementation of the framework should be abstracted accordingly. Therefore, abstraction and interfaces are the core of the framework.

 

In the history of software development, there have been an endless stream of frameworks. This is because people's ideas are still very creative, but there will be little to develop, after all, it is influenced by many factors other than technology. Broadly speaking, the structure of any software can be referred to as a framework, and the UI framework can be used to solve user interface problems. But it is not that simple.

 

UI, as its name implies, refers to the user, that is, the user interface, and the computer interface. Therefore, it was also called MMI (Man Machine inerface) earlier ). Therefore, the UI design is to solve the problem of interaction between people and computers. It can be attributed to the problem of input and output, that is, how computers can accurately and effectively accept human instructions, then, output the handling result as needed. Looking at the history of computers, from the input and output of Paper paper to today's 3D reality and touch screen, computers have indeed become more humane, the problems faced by the UI are also caused by how to use the underlying and original hardware at the very beginning to make people interact with computers more like dealing with people (after all, Communication habits between people are the most naturally ), you can even feel more illusory about the future. These changes also affect the focus of the UI framework in different periods. For example, in the early stage of the graphic interface, you must serialize user input and serialize display (do not write screens simultaneously by multiple processes or threads ), the mechanisms or frameworks such as message queues have been designed, and these become frameworks rather than applications. More importantly, they abstract a specific function and are reused by other different modules. Today, no one has spent a lot of time studying these things, because the technology is mature and the focus of the UI has shifted to the user experience. Of course, the popularity of new hardware, such as touch screens, will bring about updates to existing frameworks. However, in this era, the UI framework is more about how to provide an unprecedented user experience around OpenGL, instead of how to solve the long-known problems such as font display or effective and flexible implementation of scheme/skin.

 

Today, object-oriented uidesign has become the mainstream. Different frameworks basically implement basic abstraction of application-related classes and objects from a single base class, for example, Java object and QT qobject, And the abstraction implemented in this base class is not the UI feature. Message response mechanisms, such as message ing macros of MFC, listener of swing and SWT, and signal/slot of QT are essentially based on message queue and distribution mechanisms. For applications, more is the difference between interfaces (by the way, I firmly stand on the signal/slot side, but the details are not the focus of this Article ). More importantly, these frameworks are not only applicable to the UI, so strictly speaking, they are part of the application framework.

 

Let's talk about what is a UI application. In my understanding, this refers to the UI applications in the general sense. Physically, they usually exist in the form of a single execution file, it also depends on the general framework provided by other software libraries or background services/daemon. Therefore, they often only target a specific problem. For example, the e-mail client solves the problem of using email. Therefore, their code is usually not used by other applications or frameworks, the design is also relatively simple (my other article)
Also mentioned ).

 

The content of the same application in different environments is also different. For example, Java application design requires more considerations than osgi application design, because the osgi * framework * has designed a lifecycle management framework for its applications. In the same way, compared with QT, Kde applications can have less integration with desktop systems. This directly reflects the UI framework and mobile phone of the desktop system. The UI framework of the automotive system has different meanings.

 

All in all, I don't think the UI framework is strictly defined. As long as it can solve any basic UI problems, it is designed to be reused by other modules, especially Upper-layer modules, it can be part of the UI framework. In fact, in actual work, many of them used to be the core of the UI framework design. Now they are no longer the focus of the UI framework design. Therefore, they seem to be a matter of UI applications in the past, it is also a part of the UI framework, because the current UI application does not need to implement these functions, and in different device environments, the UI framework contains different things.