A method, framework and system for managing desktop applications based on embedded Linux Qt

Abstract

The application discloses a kind of based on embedded Linux Qt's desktop application management method, framework and system, it is related to embedded software and industrial man-machine interaction technical field, including: in response to the instruction of desktop management program, start desktop application management program, and parse preset configuration file, the application configuration information that is parsed is output to display device, to show corresponding application icon and application name on display device;In response to the application program icon being selected trigger application program running instruction, start the application program according to configuration file.The application realizes low overhead, high response multi-application desktop management in embedded Linux Qt, significantly improves user interaction smoothness and system scalability.

Description

Technical Field

[0001] This invention relates to the field of embedded software and industrial human-computer interaction technology, and in particular to a desktop application management method, framework and system based on embedded Linux Qt. Background Technology

[0002] In the field of embedded Linux devices, the Qt graphical framework, with its lightweight and cross-platform characteristics, is widely used in human-machine interaction systems for scenarios such as energy storage EMS and industrial monitoring. As device functions continue to iterate, the architecture of deploying multiple service modules independently as independent application processes has gradually become the mainstream, but the corresponding centralized desktop management mechanism has not been improved accordingly.

[0003] In existing technologies, most embedded devices use a single Qt application to integrate all business interfaces, resulting in high coupling between the interface and business logic, scattered icon loading and startup configuration, and the need to modify the main program source code and recompile the firmware to add new features, leading to low development and integration efficiency. Some solutions introduce general embedded desktop environments, but these have high resource consumption and lack a dedicated bus-based application scheduling mechanism. Switching between multiple applications in the foreground and background relies on cumbersome inter-process communication, and it is impossible to quickly wake up applications or restore the desktop through lightweight broadcasts. This results in problems such as interface switching lag and chaotic window hierarchy, making it difficult to adapt to the limited hardware resources and high reliability interaction requirements of embedded devices. Summary of the Invention

[0004] The main objective of this invention is to provide a desktop application management method, framework, and system based on embedded Linux Qt. It aims to solve the technical problems in embedded Linux Qt environments, such as the lack of centralized desktop management for multiple applications based on a bus, scattered icon loading and startup configuration, cumbersome IPC for switching between foreground and background, and the inability to quickly wake up applications or restore the desktop using lightweight broadcasting. These problems result in sluggish interface switching, complex management, and seriously affect the interactive experience and development and integration efficiency of embedded devices.

[0005] To achieve the above objectives, this invention proposes a desktop application management method applied to a system based on the embedded Linux Qt framework. The desktop application management method includes the following steps: In response to the instructions of the desktop management program, the desktop application management program is launched, and the preset configuration file is parsed. The parsed application configuration information is then output to the display device to display the corresponding application icon and application name on the display device. In response to the application icon being selected and triggering the application run command, launch the application according to the configuration file.

[0006] Furthermore, the desktop application management method also includes a preset TCP server and a TCP-based desktop bus communication mechanism; Start the TCP server and initialize the TCP-based desktop bus communication mechanism; A wake-up message carrying the application ID is broadcast via the desktop bus; the wake-up message is used to display the corresponding application at the forefront of the display screen. Multiple applications receive the wake-up message and determine whether it is their own message based on the application ID in the wake-up message. If it is, the corresponding application is displayed at the forefront of the display screen.

[0007] Furthermore, the preset TCP-based desktop bus communication mechanism includes: The desktop application management program is configured as a TCP server listening on a preset port to accept connection requests initiated by multiple applications as TCP clients. Multiple applications are configured as TCP clients, and the TCP clients are configured to actively connect to the preset port after the application starts, so as to maintain continuous communication with the desktop application management program.

[0008] Furthermore, the desktop application management method further includes: after the step of displaying the corresponding application at the forefront of the display screen, in response to the user's minimize operation of the current application, the application sends a hidden message carrying its own ID to the desktop application manager through the desktop bus; after receiving the hidden message, the desktop application manager displays the desktop application manager at the forefront of the display screen.

[0009] Furthermore, the step of responding to a user's click on any application icon and launching the application according to the configuration file also includes: checking the running status of the desktop application management program corresponding to the application icon; if the application is not launched, then launching the application according to the configuration file.

[0010] Furthermore, the configuration file contains one or more application configuration blocks, each configuration block being identified by a block header, which includes at least the application ID, executable file path, icon path, and application name; When parsing the configuration file, the application ID, path, icon, and name information in each configuration block are read by recognizing the block header in order to load the application icon and application name.

[0011] Furthermore, displaying the corresponding application icon and application name on the display device includes: Simultaneously render the application icon and the application name on the desktop of the display screen, and bind the application icon to the corresponding launch event.

[0012] This invention also proposes a desktop application management framework based on embedded Linux Qt, comprising: The configuration parsing module is used to parse the preset configuration file and extract the application configuration information of each application, including the application icon and application name; The display module is used to load the application icon and application name to the desktop and display them on the screen; The TCP server module is used to create and listen on a preset port, establish a TCP-based desktop bus, and communicate with multiple applications through the desktop bus. Multiple applications, each acting as a TCP client, connect to the preset port and maintain communication with the desktop bus after startup; The desktop application management framework controls the display of applications or desktop management programs at the forefront of the screen through the desktop bus, thereby enabling display switching.

[0013] Furthermore, the desktop application management framework is configured to: broadcast a wake-up message carrying the target application ID via the desktop bus, causing the corresponding application to be displayed at the forefront of the screen; receive a hidden message carrying its own ID sent by the application in unicast form, and restore the desktop management program to be displayed at the forefront of the screen.

[0014] The present invention also proposes a desktop application management system based on embedded Linux Qt, characterized in that it includes a desktop application management framework.

[0015] This invention uses a pre-configured configuration file to parse application IDs, icons, and paths for unified loading. The configuration file uses block headers to identify application information, ensuring efficient parsing. A TCP-based desktop bus is constructed, with the desktop management program acting as a server listening, and each application automatically connecting upon startup as a client. A wake-up message carrying the target ID is broadcast over the bus to bring the corresponding application window to the top in real time. When an application is minimized, a unicast message is sent to restore it to the foreground, forming a precise display switching loop, avoiding window hierarchy chaos, and maintaining constant communication. This achieves low-overhead, high-response multi-application desktop management in embedded Linux Qt, significantly improving user interaction smoothness and system scalability. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a diagram showing the overall layered architecture of the EMS lightweight desktop management system of the present invention. Figure 2 This is a flowchart illustrating the desktop management program's operation and application scheduling process according to the present invention. Figure 3 This is a schematic diagram of the application configuration file block structure of the present invention; Figure 4 This is a flowchart illustrating the configuration parsing and desktop icon loading process of the present invention. Figure 5 This is a schematic diagram of the TCP desktop bus message frame format of the present invention; Figure 6 This is a timing diagram of desktop bus communication interaction according to the present invention.

[0019] The objectives, features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of the present invention and are not intended to limit the present invention.

[0021] To better understand the technical solution of the present invention, a detailed description will be provided below in conjunction with the accompanying drawings and specific embodiments.

[0022] The lightweight EMS desktop framework (DesktopManager) proposed in this invention sits between the Weston desktop display system and specific applications (such as BAUQT), providing configuration file management and a TCP-based desktop bus communication mechanism for the applications. All Qt applications are hosted in DesktopManager.

[0023] Figure 1 This is a diagram showing the overall layered architecture of the EMS lightweight desktop management system of the present invention. like Figure 1As shown, the overall display system adopts a four-layer vertically stacked hierarchical architecture, consisting of a basic display layer, a desktop management layer, a business application layer, and a display output layer from bottom to top. Each layer forms a bottom-up support and top-down control relationship. The bottom layer is the Weston desktop system, which serves as the Wayland display service in an embedded Linux environment. It provides basic window composition, graphics rendering, and hardware display driver capabilities, providing a unified runtime base for all upper-layer Qt programs and shielding them from differences in underlying hardware display. Above Weston is the QT APP management process - DesktopManager, which is the core middleware layer of this framework. It connects the upper and lower layers, on the one hand, connecting with Weston to complete window hierarchy scheduling, and on the other hand, uniformly managing all business applications, undertaking three core functions: configuration parsing, application lifecycle management, and TCP desktop bus service. Above the desktop management process is the business application layer, composed of multiple independent Qt application processes running in parallel. The example in the diagram includes two types of applications: the BAUQT front-end display and the EMS process QT front-end display. These correspond to different EMS business function modules. Each application is independently developed and deployed, and all have built-in TCP client logic. They interact with the DesktopManager through the desktop bus and are subject to unified scheduling by the desktop management process. At the top of the architecture is the LCD display, which is the system's visual output outlet. All desktop icon interfaces rendered by the desktop management process and the functional interfaces rendered by each business application are ultimately output to the LCD screen through the Qt graphics framework and presented to the end user.

[0024] Figure 2 This is a flowchart illustrating the desktop management program's operation and application scheduling process according to the present invention. like Figure 2 As shown, the complete operating logic of DesktopManager is divided into two parts: the initialization main line and the button interaction branch. After the program starts, it executes sequentially along the initialization main line. Upon startup, the program first parses the configuration file, reads the configuration file under the system's preset path, and extracts the configuration information of each application. Then, it sets up the button extension component, initializing the display attributes of the desktop button controls, such as icons and names, based on the parsed icon and name configurations. Next, it adds the configured button controls to the home button display area according to the preset layout, completing the layout rendering of the desktop interface. Afterward, it sets a button callback for each button control, binds the click callback function, and associates the button with the startup and switching logic of the corresponding application. After the callback binding is completed, it starts the TCP APP notification server, starts the TCP server and binds the preset port, completing the initialization of the TCP-based desktop bus and entering the port listening state. Finally, it enters the state of waiting for APP connections, with the server continuously running, waiting for various business applications to initiate connection requests as clients, and simultaneously waiting for user button interaction operations.

[0025] When a user clicks any application icon button on the desktop, the corresponding callback logic is triggered. First, the button press operation is captured, and the application identifier bound to the button is obtained. Then, it checks whether the bound APP is running, and whether the corresponding application has been launched and connected to the desktop bus. If it is determined that the application is not running, the program launch command is executed, and the corresponding application process is created and launched according to the executable file path recorded in the configuration file. If it is determined that the application is already running, an APP wake-up command is sent via TCP, and a wake-up instruction is sent to the corresponding application via the desktop bus to switch its window to the foreground of the display.

[0026] This embodiment provides a lightweight desktop management method for EMS that supports multiple applications. The method includes the following steps: in response to the startup command of the desktop management program, parsing a preset configuration file and outputting the parsed application configuration information to a display device to display the corresponding application icon and application name on the display device; in response to the application running command triggered by the selection of the application icon, starting the application according to the configuration file.

[0027] In implementation, the DesktopManager is designed as a daemon process that starts automatically upon system boot. After the embedded Linux system completes initialization and starts the Weston display service, the DesktopManager is automatically launched by the system startup script. The first core task executed after startup is to load and parse a preset configuration file. This configuration file is stored in a fixed path preset by the framework, such as " / opt / ems / config / applications.ini". System integrators or on-site maintenance personnel can manage all available application entry points by editing this file.

[0028] After the desktop management framework starts, it reads four key factors for each application according to the preset configuration file: the first is the application ID, which is used for communication identification on the desktop bus and serves as a unique identifier for the application instance within the entire framework; the second is the path to the executable file, which the desktop management framework uses to launch the corresponding application process via QProcess when the user clicks the application icon; the third is the icon path, which is used to display the corresponding application icon on the desktop, and this icon is usually a PNG image resource; the fourth is the application name, which is used to display the name of the application as a text label on the LCD for easy identification by on-site operators.

[0029] Figure 3 This is a schematic diagram of the application configuration file block structure of the present invention; See Figure 3The configuration file consists of one or more configuration blocks, each containing five parts. The configuration file contains one or more application configuration blocks, each identified by a block header, which includes at least the application ID, executable file path, icon path, and application name. The block header is fixed as "[App]". When the desktop manager parses the configuration file, it reads the application ID, path, icon, and name information from each configuration block by recognizing the block header, in order to load the application icon and application name. The parsing process uses a line-by-line scanning method. After opening the configuration file, the program reads line by line. When it scans a line starting with "[App]", it recognizes it as the start marker of a new configuration block. Subsequently, it parses key-value pairs such as "Id=", "path=", "icon=", and "name=" in the lines below it, until it encounters the next block header or the end of the file. Each complete set of parsed information is encapsulated into an internal data structure and added to the application information list maintained by the desktop manager.

[0030] Specifically, the application ID is defined as "Id=xxx", where xxx represents the corresponding application ID, identified by numbers, such as "Id=1", "Id=2", etc. This numeric ID is used to uniquely identify the corresponding application during desktop bus communication. The path information is defined as "path=xxx", where xxx represents the complete path information of the corresponding executable program, such as "path= / opt / ems / apps / bau_monitor". When the desktop management program needs to launch the application, it passes this path to the QProcess startup process. The icon information is defined as "icon=xxx", where xxx represents the path information of the application icon, defined as a PNG format, such as "icon= / opt / ems / res / bau_icon.png". The desktop management program loads this icon file and renders it as the application icon on the desktop. The program name is defined as "name=xxx", where xxx represents the display name of the application, such as "name=Battery Management Unit Monitor". The desktop management program uses this name to render the corresponding text label below the icon on the LCD.

[0031] Figure 4 This is a flowchart illustrating the configuration parsing and desktop icon loading process of the present invention. The process is as follows: Figure 4As shown, after the desktop management application starts, it checks the configuration files one by one, extracts all application configurations based on the block information, and loads the application icons and names onto the desktop. In the step of displaying the corresponding application icons and names on the display device, the desktop management program simultaneously renders the application icon and name on the desktop and binds the application icon to the corresponding launch event. In the Qt framework, this process is specifically manifested as follows: the desktop management program traverses the parsed application information list, and for each application item, uses a QIcon to load the image resource pointed to by the icon path, creates a QPushButton or a clickable QWidget as the icon carrier, sets the icon on it, and places a QLabel below it to display the application name. Then, these controls are arranged in a designated area of ​​the desktop window according to a preset layout strategy (such as grid layout or list layout). Simultaneously, through Qt's signal and slot mechanism, the click signal of each icon control is connected to a unified slot function. This slot function internally executes subsequent launch or wake-up logic by reading the application ID associated with the trigger control. When the user clicks the application icon via a touchscreen or mouse, the application execution command is triggered. In the steps described above—responding to a user's click on any application icon and launching the application according to the configuration file—the desktop management application first checks the running status of the application corresponding to the application icon. Internally, the desktop management program maintains an active application connection pool, which records information about all applications that have been launched and established TCP connections with the desktop bus, including the application ID, the corresponding socket descriptor, and the connection status. The program determines whether the application has been launched by querying the connection pool to see if a valid connection entry matching the target application ID exists. If the query result indicates that the connection corresponding to the application ID does not exist or has been broken, the application is determined not to be launched, and the desktop management program calls QProcess to launch the application process according to the executable file path recorded in the configuration file. If the query result indicates that the application has been launched and the connection is valid, the process is not launched again; instead, a wake-up message is sent to the application via the desktop bus, directly switching its existing window to the foreground.

[0032] After the application starts, since each cold start takes a considerable amount of time, to improve the user experience, the application is no longer closed after launch but remains in the background. This design means that the application process will continue to run in the system background after the initial launch; its window can be hidden, but the process itself does not exit. When the user clicks the desktop icon again, there is no need to go through the complete process loading and interface initialization process; the application window can be restored to the foreground of the LCD in a very short time simply through message interaction on the desktop bus, thus achieving a "hot-swap" user experience. This persistence mechanism is particularly suitable for use scenarios on embedded devices where applications frequently switch, significantly improving the timeliness of operation response.

[0033] The desktop management method in this embodiment also includes a preset TCP server and a TCP-based desktop bus communication mechanism. In specific implementation, after parsing the configuration file and loading the desktop icons, the desktop management program immediately starts the TCP server and initializes the TCP-based desktop bus communication mechanism. The desktop management program creates a QTcpServer object, calls its listen method to bind to a preset local port, and connects the newConnection signal to the corresponding slot function to handle new client connection requests.

[0034] Regarding the pre-defined TCP-based desktop bus communication mechanism, the desktop application management program is specifically configured as a TCP server listening on a preset port to accept connection requests initiated by multiple applications as TCP clients. Multiple applications are configured as TCP clients, and these clients are configured to actively connect to the preset port after application startup, maintaining continuous communication with the desktop application management program. In this embodiment, the desktop management framework's TCP server continuously listens on the preset port 10013 after startup. This port number is a pre-defined constant of the framework and remains consistent across the desktop management program and all applications developed in accordance with this framework specification. After an application starts, its integrated TCP client module automatically initiates a connection request to port 10013 at its local address during the initialization phase, establishing a long-lived TCP connection with the desktop management program. Upon accepting a new connection, the desktop management program obtains the QTcpSocket object for that connection, adds it to the connection pool for management, and sends an identity query message through the connection to request the client to reply with its application ID, thereby binding the connection to a specific application ID.

[0035] Figure 5 This is a schematic diagram of the TCP desktop bus message frame format of the present invention; Figure 6 This is a timing diagram of desktop bus communication interaction according to the present invention; See Figure 5 and Figure 6 The desktop bus communication mechanism is a client / server model based on TCP and is an important component of the desktop management framework. In this framework, after an application starts, due to the significant time required for each cold start, to improve user experience, the application is not closed after startup but remains in the background. Relying on the desktop management framework, the display and hiding of multiple applications requires communication between the desktop bus and the desktop management application. Communication methods support both broadcast and unicast modes. Broadcast mode allows the desktop management program to simultaneously notify all connected applications, which then filter based on the target ID in the message. Unicast mode allows a single application to send a message to the desktop management program point-to-point, such as requesting to hide itself.

[0036] The desktop bus messages employ a lightweight, custom format consisting of three parts: an identifier header, an ID, and an opcode. The identifier header verifies message validity. When parsing a message, the receiving end first checks if the identifier header matches a preset value; if not, the message is discarded, thus filtering out invalid data or noise on the bus. The ID number is used by each application to filter whether a message is intended for itself. -1 represents broadcast; when an application receives a message with an ID of -1, it indicates the message is intended for all devices, requiring further parsing to determine whether to respond. When the ID is a specific value, only applications whose ID precisely matches that value will process the message. The opcode defines two modes: 0 represents hidden, and 1 represents shown, corresponding to the background hiding and foreground waking operations of the application window, respectively. This simple three-field message format satisfies the functional requirements of desktop management while minimizing communication overhead, making it suitable for lightweight data transmission in embedded environments.

[0037] When the desktop management program is displayed in the foreground, i.e., the LCD screen currently displays the main desktop interface with application icons arranged, clicking an application icon on the desktop triggers the slot function of the desktop management framework. If the application is already running, the framework broadcasts a wake-up message carrying the application ID via the desktop bus. This wake-up message is used to display the corresponding application in the foreground. The target ID in the message is explicitly defined in the application configuration block of the configuration file and has a one-to-one correspondence with the ID within the application. The framework iterates through all active sockets in the connection pool, writing the constructed wake-up message to each socket one by one, thus achieving broadcast transmission.

[0038] Multiple applications receive the wake-up message and determine whether it is a message for themselves based on the application ID in the wake-up message. All applications that receive the broadcast message first verify the identifier header in their respective message handling functions. If the verification is successful, the ID field is parsed and compared with its own application ID. If the IDs match, it is determined that the message is a wake-up command sent to itself, and the corresponding application is displayed at the forefront of the screen. The target application then calls Qt's `show()` function to redisplay the window and calls `raise()` and `activateWindow()` functions to elevate the window to the top of the window stack, ensuring the window receives input focus. Simultaneously, the desktop manager calls `hide()` or `lower()` functions to hide or lower its own window, completely transferring control of the LCD display to the target application. If the IDs do not match, the application ignores the broadcast message and continues to maintain its current state.

[0039] Furthermore, following the step of displaying the corresponding application on the foreground of the screen, this method also includes minimize-to-restore processing logic. When a user is using an application that is currently displayed on top, they click the minimize button provided in the application window title bar or interface. The application's internal logic captures this minimize operation event and, just before the window is about to be hidden, sends a hide message to the desktop management framework via an established TCP connection in unicast format. This hide message uses the same three-field format, where the ID field is filled with the application's own ID, and the opcode is 0 to indicate hiding.

[0040] Upon receiving the hide message, the desktop application manager reads the message's opcode in the message processing slot function, determining that the corresponding application has actively requested to go to the background and has already hidden or minimized its own window. The desktop manager then brings the desktop application manager to the forefront of the display, calling functions such as show(), raise(), and activateWindow() to bring the main desktop window back to the top of the LCD and gain focus, restoring the desktop to a state where all application icons are displayed, achieving exclusive display. The application itself, after sending the hide message, calls hide() to hide its window, while the process continues to run in the background, maintaining a continuous TCP client connection, ready to receive the next wake-up command.

[0041] By combining these two message types, the application's unicast notification is hidden and returns foreground control, while the desktop manager broadcasts a message carrying the target ID to wake up the corresponding application and hides itself, achieving seamless switching between multiple applications on the LCD screen. Throughout the switching process, for the user, the response time from clicking the desktop icon to the application appearing in full screen is in milliseconds, providing a smooth and lag-free experience. For the system, the window hierarchy is always centrally managed by the desktop manager, avoiding display chaos caused by multiple application windows vying for top position simultaneously.

[0042] This embodiment also provides a lightweight desktop management framework based on embedded Linux Qt. Corresponding to the above method, the framework includes the following modules: a configuration parsing module, used to parse a preset configuration file and extract application configuration information of each application, the application configuration information including application icon and application name; a display module, used to load the application icon and application name to the desktop and display it on the screen. In this embodiment, this module uses Qt's QWidget, QIcon, and QLabel controls to render the desktop interface; a TCP server module, used to create and listen to a preset port, establish a TCP-based desktop bus, and communicate with multiple applications through the desktop bus. In this embodiment, this module is implemented based on QTcpServer; multiple applications, each acting as a TCP client, connect to the preset port and maintain communication with the desktop bus after startup. In this embodiment, each application integrates a client communication component based on QTcpSocket; wherein, the desktop management framework controls the application or desktop management program to be displayed at the forefront of the screen through the desktop bus, realizing display switching.

[0043] Specifically, the aforementioned desktop management framework is configured to: broadcast a wake-up message carrying the target application ID via the desktop bus, causing the corresponding application to appear on the foreground of the display; receive a hidden message carrying its own ID sent by the application in unicast form, and restore the desktop management program to appear on the foreground of the display. This configuration unifies the two symmetrical scenarios of window switching into the framework's management logic, allowing application developers to seamlessly integrate independently developed Qt applications into the entire EMS desktop management system by implementing minimal bus message sending and receiving logic within the application itself, without needing to concern themselves with the underlying window hierarchy operations and inter-process communication details.

[0044] This embodiment also provides a desktop application management system based on embedded Linux Qt. This system includes the aforementioned lightweight desktop management framework and multiple EMS applications running on it. In a complete system deployment, the desktop management framework starts with the system as a daemon process. It first reads the configuration file to build the desktop icon interface, and then starts the TCP server to enter a listening state. Each EMS application can be configured to start automatically or manually by the user via the desktop after system startup, and automatically connects and registers to the desktop bus after startup. The entire EMS display system operates in an orderly manner around the desktop bus, forming a complete, scalable, pluggable application display management platform.

[0045] Through the above scheme, this invention achieves a combination of "configuration as menu" and "desktop bus communication". At the configuration file level, adding an EMS application only requires adding a "[App]" configuration block to the configuration file, filling in the corresponding ID, path, icon, and name (four lines of information); removing an application only requires deleting or commenting out the corresponding configuration block. The entire process does not require modifying the source code of the desktop management program or recompiling the firmware, thus achieving dynamic addition and deletion of the LCD interface, truly realizing "hot-swappable" application management. At the communication level, the desktop bus's broadcast wake-up and unicast hiding mechanisms provide lightweight and efficient underlying support for seamless switching between multiple applications. All window management commands are transmitted on the TCP local loopback interface with extremely low latency, ensuring the real-time performance of switching operations.

[0046] This invention unifies the parsing of application IDs, icons, and paths through pre-configured configuration files, using block headers to identify each application configuration to ensure efficient parsing. It constructs a TCP-based desktop bus, with the desktop management program acting as a server listening, and each application automatically connecting upon startup as a client. By broadcasting a wake-up message carrying the target ID via the bus, the corresponding application window is brought to the top in real time. When an application is minimized, a unicast hidden message is sent to restore it to the foreground, forming a precise display switching loop and avoiding window hierarchy confusion. This achieves low-overhead, high-response multi-application desktop management in embedded Linux Qt, enabling large-scale energy storage EMS systems to possess true application plug-in display management capabilities. On-site application installation or uninstallation requires only a single line of configuration modification to add or remove LCD interfaces, significantly improving the flexibility and scalability of large-scale energy storage systems while greatly reducing engineering maintenance costs and firmware iteration risks.

[0047] The above description is only a part of the embodiments of the present invention and does not limit the patent scope of the present invention. All equivalent structural transformations made under the technical concept of the present invention using the contents of the present invention specification and drawings, or direct / indirect applications in other related technical fields, are included within the patent protection scope of the present invention.

Claims

1. A desktop application management method, applied to a system based on the embedded Linux Qt framework, characterized in that, The desktop application management method includes the following steps: In response to the instructions of the desktop management program, the desktop application management program is launched, and the preset configuration file is parsed. The parsed application configuration information is then output to the display device to display the corresponding application icon and application name on the display device. In response to the application icon being selected and triggering the application run command, launch the application according to the configuration file.

2. The desktop application management method as described in claim 1, characterized in that, The desktop application management method also includes a preset TCP server and a TCP-based desktop bus communication mechanism; Start the TCP server and initialize the TCP-based desktop bus communication mechanism; A wake-up message carrying the application ID is broadcast via the desktop bus; The wake-up message is used to display the corresponding application at the forefront of the display screen; Multiple applications receive the wake-up message and determine whether it is their own message based on the application ID in the wake-up message. If it is, the corresponding application is displayed at the forefront of the display screen.

3. The desktop application management method as described in claim 1, characterized in that, The preset TCP-based desktop bus communication mechanism includes: The desktop application management program is configured as a TCP server listening on a preset port to accept connection requests initiated by multiple applications as TCP clients. Multiple applications are configured as TCP clients, and the TCP clients are configured to actively connect to the preset port after the application starts, so as to maintain continuous communication with the desktop application management program.

4. The desktop application management method as described in claim 2, characterized in that, The desktop application management method further includes: after the step of displaying the corresponding application at the forefront of the display screen, in response to the user's minimize operation of the current application, the application sends a hidden message carrying its own ID to the desktop application manager through the desktop bus; after receiving the hidden message, the desktop application manager displays the desktop application manager at the forefront of the display screen.

5. The desktop application management method as described in claim 1, characterized in that, The step of responding to a user's click on any application icon and launching the application according to the configuration file further includes: checking the running status of the desktop application management program corresponding to the application icon; if the application is not launched, then launching the application according to the configuration file.

6. The desktop application management method according to claim 1, characterized in that, The configuration file contains one or more application configuration blocks, each of which is identified by a block header and includes at least the application ID, executable file path, icon path, and application name; When parsing the configuration file, the application ID, path, icon, and name information in each configuration block are read by recognizing the block header in order to load the application icon and application name.

7. The desktop application management method according to claim 1 or 6, characterized in that, The step of displaying the corresponding application icon and application name on the display device includes: Simultaneously render the application icon and the application name on the desktop of the display screen, and bind the application icon to the corresponding launch event.

8. A desktop application management framework based on embedded Linux Qt, characterized in that, include: The configuration parsing module is used to parse the preset configuration file and extract the application configuration information of each application, including the application icon and application name; The display module is used to load the application icon and application name to the desktop and display them on the screen; The TCP server module is used to create and listen on a preset port, establish a TCP-based desktop bus, and communicate with multiple applications through the desktop bus. Multiple applications, each acting as a TCP client, connect to the preset port and maintain communication with the desktop bus after startup; The desktop application management framework controls the display of applications or desktop management programs at the forefront of the screen through the desktop bus, thereby enabling display switching.

9. The desktop application management framework according to claim 8, characterized in that, The desktop application management framework is configured as follows: A wake-up message carrying the target application ID is broadcast via the desktop bus, causing the corresponding application to be displayed at the forefront of the screen. Receive a hidden message carrying its own ID sent by the application in unicast form, and restore the desktop manager to the foreground of the display.

10. A desktop application management system based on embedded Linux Qt, characterized in that, Includes the desktop application management framework as described in any one of claims 8 or 9.

Images