Method and device for recovering desktop environment based on bottom-layer-front-end native signal

Abstract

The application discloses a desktop environment management and control recovery method and device based on bottom-layer-front-end native signals, and relates to the technical field of computers, which comprises the following steps: generating a structured capability set file when a desktop component is installed and summarizing the file into global capability set information, obtaining a to-be-issued management and control strategy and verifying the strategy, converting the strategy into a bottom-layer configuration by a configuration management and control service process, writing the configuration into a system-level overlay configuration file and a lock list file, and updating a bottom-layer configuration database; triggering a front-end configuration interface to monitor changes, broadcasting a native data change signal to a component, calling a writeability query interface by the component, and adaptively adjusting a UI display state. Through complete decoupling of the management and control strategy and the desktop component version, a data-driven management and control issuing closed loop is realized, communication strong coupling between a management and control service and a desktop component is eliminated, the stability of the system under high-concurrency management and control and abnormal scenarios is improved, and lossless automatic recovery of user individual configuration after domain withdrawal is ensured.

Description

Technical Field

[0001] This invention relates to the field of Linux desktop environment technology, and in particular to a desktop environment management and recovery method and apparatus based on low-level-front-end native signals. Background Technology

[0002] Existing Linux desktop management typically employs a custom signal notification model. After configuration changes are made on the management end, a custom signal (such as ConfigChanged) is sent via the System Bus. Desktop components need to listen for this specific System Bus signal to refresh their state. To ensure the modified configuration takes effect, desktop components must add hard-coded configuration to their front-end code to listen for this specific custom bus signal. Upon receiving the signal, they then fetch the latest configuration data to refresh the user interface. This approach heavily relies on the management service process and its interface definition. Furthermore, sending upper-level notifications while modifying the underlying configuration increases the complexity of system-level IPC communication and system load. When a desktop component leaves the domain or is removed from management, complex logic needs to be executed to restore user settings. Directly deleting the configuration file can easily lead to the loss of user settings, while retaining the file may result in residual management data.

[0003] However, once a custom signal or interface changes, all related desktop components need to be recompiled and modified to adapt the code, resulting in inflexible policy delivery. There is also a risk that custom signals or interfaces may be hijacked by low-privilege processes due to lack of strict authentication. Summary of the Invention

[0004] This invention provides a desktop environment management and recovery method and apparatus based on bottom-front-end native signals to solve the technical problem that the communication coupling between desktop components and management services leads to configuration loss or residue when leaving the domain, thus making it impossible to automatically restore the user's personalized settings in the desktop environment without loss.

[0005] In a first aspect, embodiments of the present invention provide a desktop environment management and recovery method based on bottom-end-front-end native signals, including: S101 generates a structured capability set file in a preset directory during desktop component installation. It uses the configuration management service process to scan the preset directory, extract all structured capability set files to form global capability set information, and provides query services to the outside world through a preset interface. S102: Use the domain management client to obtain the management policy to be issued, and use the preset interface to verify its legality based on the global capability set information. After the verification is successful, call the preset policy issuance interface, use the configuration management service process to perform Dconf database-recognizable transformation of the management policy to be issued, form the underlying configuration information and write it into the system-level overriding configuration file, and at the same time write the configuration item that needs to be forcibly managed into the lock list file to update the underlying configuration database. S103 After the underlying configuration database is updated, the front-end configuration interface is triggered to monitor the changes in the underlying data and broadcast the native data change signal to the desktop components that have been bound to the configuration item identifier. The desktop components call the writability query interface to query the writability status of the corresponding configuration item and adaptively adjust the UI display status of the user interface controls.

[0006] Secondly, embodiments of the present invention provide a desktop environment management and recovery device based on bottom-front-end native signals, comprising: The capability set construction module is used to generate structured capability set files in a preset directory when desktop components are installed. It uses the configuration management service process to scan the preset directory, extract all structured capability set files to form global capability set information, and provides query services to the outside world through a preset interface. The configuration update module is used to obtain the management policy to be issued by the domain management client, and to perform legality verification based on the global capability set information through the preset interface. After the verification is successful, the preset policy issuance interface is called. The configuration management service process performs a Dconf database-recognizable transformation on the management policy to be issued, forms the underlying configuration information and writes it into the system-level overriding configuration file. At the same time, the configuration items that need to be forcibly managed are marked and written into the lock list file to update the underlying configuration database. The display update module is used to trigger the front-end configuration interface to monitor the changes in the underlying data after the underlying configuration database is updated, and broadcast the native data change signal to the desktop components that have been bound to the configuration item identifier in advance. The desktop components call the writability query interface to query the writability status of the corresponding configuration item and adaptively adjust the UI display status of the user interface controls.

[0007] Thirdly, embodiments of the present invention provide an electronic device, including: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the above-described desktop environment management and recovery method based on low-level-front-end native signals.

[0008] Fourthly, embodiments of the present invention provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the aforementioned desktop environment management and recovery method based on low-level-front-end native signals.

[0009] This invention provides a desktop environment management and recovery method and apparatus based on bottom-end and front-end native signals. The method automatically generates a structured capability set file during desktop component installation, scans and summarizes it into global capability set information, and provides it for external querying. The domain management client obtains the management policy to be issued and verifies it according to the global capability set information. Then, the configuration management service process converts it into bottom-end configuration information and writes it into a system-level overlay configuration file, and writes the management identifier into a lock list file, thereby updating the bottom-end configuration database. This triggers the front-end configuration interface to monitor changes and broadcasts a native data change signal to the bound desktop component. The desktop component then calls the writability query interface to adaptively adjust the display state of the user interface. By automatically generating and aggregating capability set files during component installation, the management end can dynamically determine the actual policy range supported by the terminal, completely decoupling the management policy from the desktop component version. By directly converting the policy into overwrite and lock files of the underlying database, a data-driven management and control closed loop is achieved. By automatically triggering native data change signals of the front-end interface through underlying data updates, and combined with the front-end writability status query, the desktop component can automatically complete the forced graying and refresh of the interface without listening to any custom inter-process communication signals, eliminating the strong coupling of communication between the management service and the desktop component, and improving the stability of the system under high-concurrency management and abnormal scenarios. Attached Figure Description

[0010] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a flowchart of a desktop environment management and recovery method based on bottom-end-front-end native signals, as described in Embodiment 1 of the present invention. Figure 2 This is a flowchart of a desktop environment management and recovery method based on bottom-end-front-end native signals, as described in Embodiment 2 of the present invention. Figure 3 This is a schematic diagram of the structure of a desktop environment management and recovery device based on bottom-end-front-end native signals as described in Embodiment 3 of the present invention; Figure 4 This is a structural diagram of the electronic device described in Embodiment 4 of the present invention. Detailed Implementation

[0011] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0012] Example 1 Figure 1 The flowchart of a desktop environment management and recovery method based on bottom-end-front-end native signals according to Embodiment 1 of the present invention specifically includes the following steps: S101 generates a structured capability set file in a preset directory during desktop component installation. It then uses the configuration management service process to scan the preset directory, extract all structured capability set files to form global capability set information, and provides query services to the outside world through a preset interface.

[0013] During the installation of desktop components such as file managers and control panels, a structured capability set file describing its own management capabilities is automatically generated in a specified preset directory (this file is included when the component is packaged). This file declares the specific functions that the desktop component supports for management. Then, a persistent background configuration management service process scans the preset directory, extracts and parses each structured capability set file, and merges them into a global capability set. At this point, the configuration management service process exposes the global capability set information to the outside world through a system-level preset interface, providing external query services.

[0014] S102 uses the domain management client to obtain the management policy to be issued, and performs legality verification based on the global capability set information through a preset interface. After the verification is successful, the preset policy issuance interface is called. The configuration management service process performs a Dconf database-recognizable transformation on the management policy to be issued, forms the underlying configuration information and writes it into the system-level overriding configuration file. At the same time, the configuration items that need to be forcibly managed are marked and written into the lock list file, and the underlying configuration database is updated.

[0015] When a user issues a control policy via the cloud, the domain management client first receives the policy. It then calls a pre-exposed interface to retrieve global capability set information and validate the policy's validity. Validation is successful only if each control item in the policy matches a value in the global capability set. After successful validation, the domain management client calls the pre-existing policy issuance interface, handing the policy issuance task over to the configuration management service process. The configuration management service process converts the policy into a key-value pair format that the underlying configuration database (Dconf) can directly recognize, forming the underlying configuration information. This information is then written to the system's system-level overriding configuration file to correctly identify the configuration content. An update is triggered via the configuration update command (dconf update) and takes effect. Simultaneously, to enforce control, the configuration management service process extracts the identifiers of the configuration items requiring enforcement (via gsettings writable). Check whether the corresponding configuration item is under control (such as the specific key path) and write it to the system's lock list file. By writing to the lock file, it is ensured that the controlled configuration item is forcibly locked at the underlying database level, and any modification attempt will be intercepted or forcibly restored to the locked value. Finally, the configuration control service process triggers an update command to the underlying configuration database to make the above file changes take effect.

[0016] S103 After the underlying configuration database is updated, the front-end configuration interface is triggered to monitor the changes in the underlying data and broadcast the native data change signal to the desktop components that have been bound to the configuration item identifier. The desktop components call the writability query interface to query the writability status of the corresponding configuration item and adaptively adjust the UI display status of the user interface controls.

[0017] To decouple the management service from desktop components, reduce reliance on custom signals for inter-process communication, and avoid the complex task of recompiling and adapting all desktop components when the interface changes, a native data change signal is automatically captured by the file monitoring mechanism after the underlying configuration database is updated. This automatically triggers the front-end configuration interface to monitor the changes in the underlying data. Upon detecting data modification and locking, the front-end configuration interface proactively broadcasts a native data change signal to all running desktop components that have pre-bound identifiers for the corresponding configuration items in their code. This native data change signal is a system-built-in standard signal, not a custom notification signal from the configuration management service process, thus decoupling reliance on custom signals for inter-process communication. Upon receiving the broadcast native data change signal, the desktop component calls the writability query interface provided by the front-end configuration interface via a callback function to check the writability status of configuration items affected by the current policy. Based on the writable status, the desktop component adaptively adjusts accordingly, changing the UI display state of user interface controls, thereby achieving a forced management refresh of the interface with zero IPC coupling.

[0018] This embodiment automatically generates a structured capability set file during desktop component installation, scans and summarizes it into global capability set information, and provides it for external querying. The domain management client obtains the management policy to be issued and verifies it according to the global capability set information. Then, the configuration management service process converts it into underlying configuration information and writes it into a system-level overlay configuration file, and writes the management identifier into a lock list file, thereby updating the underlying configuration database. This triggers the front-end configuration interface to monitor changes and broadcasts a native data change signal to the bound desktop component. The desktop component then calls the writability query interface to adaptively adjust the display state of the user interface. By automatically generating and summarizing the capability set file during component installation, the management end can dynamically know the actual policy range supported by the terminal, completely decoupling the management policy from the desktop component version. By directly converting the policy into the overlay and lock files of the underlying database, a data-driven management issuance closed loop is achieved. By automatically triggering the native data change signal of the front-end interface through underlying data updates, and combined with the front-end writability status query, the desktop component can automatically complete the forced graying and refresh of the interface without listening to any custom inter-process communication signals, eliminating the strong coupling of communication between the management service and the desktop component, and improving the stability of the system under high-concurrency management and abnormal scenarios.

[0019] Example 2 Figure 2 This is a flowchart of a desktop environment management and recovery method based on bottom-end-front-end native signals according to Embodiment 2 of the present invention. This embodiment is based on the above embodiment and optimized. In this embodiment, S103 is specifically optimized as follows: After the Dconf database is compiled, the front-end configuration interface is triggered to recognize the changes in the underlying configuration information, forming a native data change signal, which is then broadcast to the desktop components that have been pre-bound with the corresponding configuration item identifiers, and no longer sends custom inter-process communication signals. After receiving the broadcast native data change signal, the desktop component calls the callback function of the native data change signal and iterates through the user interface controls in the desktop component that are affected by the configuration item identifier. The desktop component calls the writability query interface to query the writability status of the configuration items of the affected user interface controls, and adjusts the display status of the user interface controls based on the return value.

[0020] Accordingly, the desktop environment management and recovery method based on bottom-end-front-end native signals provided in this embodiment specifically includes: S201 generates a structured capability set file in a preset directory during desktop component installation. It then uses the configuration management service process to scan the preset directory, extract all structured capability set files to form global capability set information, and provides query services to the outside world through a preset interface.

[0021] Specifically, when installing the software package for the desktop component, a structured capability set file is generated in a preset directory to describe the control support items. The structured capability set file includes the controlled component name, the configuration items that support control, and the configuration item type.

[0022] When installing packages for desktop components, the installation script generates a structured capability set file in a preset directory (such as / opt / system / conf / ukui-security-support / ). The structured capability set file is a JSON format file, which includes the names of the controlled components that support management, such as org.ukui.peony.settings; the identifiers of the configuration items that support management, i.e., configuration keys, such as show-open-terminal, trash-icon-visible / enable-shortcut-keys; and their data types, such as bool.

[0023] The USD daemon is started as a configuration management service process. It scans the preset directory, extracts all structured capability set files and performs format verification, and integrates the verified structured capability set files to form global capability set information.

[0024] When the system boots up or the service starts, the USD (UKUI Security Daemon) daemon process is started as a configuration management service process. The USD daemon process is a resident service process running in the background of the system. It uses the USD process to scan the preset directory, extract all JSON files in it, and perform syntax and format validation. After the validation is passed, all files are merged and deduplicated to form a complete global capability set information file, such as ukui-support.json, which summarizes the complete set of management items supported by all desktop components currently installed on the system.

[0025] The configuration management service process returns the file path of global capability set information through a preset query interface exposed by the system bus, which is then called by the domain management client to dynamically obtain global capability set information and query the management items supported by the current desktop environment.

[0026] The USD process exposes a pre-defined query interface on the System DBus, such as QstringGetUkuiSupport(). This interface returns the file path of the global capability set information, which the domain management client can call through DBus to dynamically obtain and parse the merged global capability set JSON file and learn about all the management items supported by the current desktop environment.

[0027] S202 uses the domain management client to obtain the management policy to be issued, and performs legality verification based on the global capability set information through a preset interface. After successful verification, the preset policy issuance interface is called, and the configuration management service process performs a Dconf database-recognizable transformation on the management policy to be issued, forming the underlying configuration information and writing it into the system-level overriding configuration file. At the same time, the configuration items that need to be forcibly managed are marked and written into the lock list file, and the underlying configuration database is updated.

[0028] Specifically, the domain management client calls the preset interface of the configuration management service process to obtain global capability set information, and performs dynamic queries based on the management policy to be issued to verify its legitimacy.

[0029] The domain management client is a management agent program running on the controlled terminal, maintaining communication with the cloud policy server. When the domain management client receives a management policy to be issued from the cloud, it uses DBus to call the GetUkuiSupport() interface provided by the USD daemon to obtain the global capability set file path. It then reads and parses this file to obtain a list of all management items supported by the current desktop environment and their data types. The domain management client iterates through each management item in the policy to be issued, searching for a match in the global capability set information. If all configuration keys in the policy are included in the JSON list, the policy is considered valid. If a management item is not present in the global capability set information or exists but its data type does not match, the policy is determined to contain a management item not supported by the current environment, issuance is rejected, and an error response is returned to the upstream server.

[0030] After verification, the domain management client calls the policy distribution interface of the configuration management service process to transmit the management policy to be distributed to the configuration management service process. The configuration management service process converts the management policy to be distributed into a format recognizable by the Dconf database, forms the underlying configuration information, and writes it to the system-level overriding configuration file. At the same time, it writes the key-value paths of the configuration items that need to be forcibly controlled to the lock list file.

[0031] At this point, the domain management client calls the USD daemon's policy distribution interface via DBus, such as the `BoolUpdateConfig(QString configPath, QString userName)` interface. The USD process no longer sends any IPC signals to the desktop component; instead, it converts the management policy to be distributed into a format recognizable by Dconf and writes it to the underlying configuration database's system-level overwrite configuration file, such as ` / etc / dconf / db / local.d / 99-security-config`. Simultaneously, the USD process also writes the key paths that need to be forcibly locked, in plain text format, line by line, to the underlying configuration database's lock list file, such as ` / etc / dconf / db / local.d / locks / security-locks`. The underlying configuration database is the Linux system's Dconf database.

[0032] The configuration management service process compiles the underlying configuration database, uses the front-end configuration interface to identify changes in the underlying configuration information, updates the underlying configuration database, and makes the system-level overwrite configuration files and lock list files effective.

[0033] After writing the system-level overwrite configuration files and lock list files, the USD process executes the update command for the underlying configuration database (i.e., the Dconf database), namely the `sudo dconf update` command. This compiles all overwrite configuration files and lock list files in the ` / etc / dconf / db / local.d / ` directory into the Dconf binary database, recompiles and reorganizes the Dconf database to generate a binary profile library that the system can directly read, thus making the underlying data overwrite and lock updates officially effective.

[0034] After the S203 Dconf database is compiled, the front-end configuration interface is triggered to recognize the changes in the underlying configuration information, forming a native data change signal, which is then broadcast to the desktop components that have been pre-bound with the corresponding configuration item identifiers. Custom inter-process communication signals are no longer sent.

[0035] After the `dconf update` operation on the Dconf database completes, the database inode changes. This triggers the internal listening mechanism of the front-end configuration interface, which detects the inode or content change. The front-end configuration interface is the Gsettings interface, which internally implements a mechanism to monitor changes in the inode or content of the Dconf database file. When Gsettings detects a change, it immediately generates a native data change signal, which is the built-in standard `changed` signal. Since the desktop components have pre-bound their UI controls to the Gsettings `changed` signal during code initialization using standard functions such as `g_signal_connect`, Gsettings directly broadcasts this signal to the relevant desktop components that have been bound to the corresponding key. At this time, the USD process does not need to, and will not, send any custom inter-process communication (IPC) signals to the desktop components.

[0036] S204. During the code initialization phase, the desktop component creates a Gsettings object using g_settings_new("org.ukui.peony.settings"). This object binds to the configuration item identifier it is interested in through the g_signal_connect() function, and establishes a connection with the callback function of the native standard changed signal. When the desktop component receives the broadcast native changed signal, it triggers the call to the connected callback function, and iterates through the user interface controls in the current page desktop component that are affected by the configuration item identifier.

[0037] S205, the desktop component calls the writability query interface to query the writability status of the configuration items of the affected user interface controls, and adjusts the display status of the user interface controls based on the return value.

[0038] For each affected UI control that has been traversed, i.e. has a corresponding key-value path (Key) bound to it, the desktop component calls the writability query interface provided by Gsettings, such as calling the g_settings_is_writable(settings, key) function, passing in the current Gsettings object and the configuration key (Key), to query its writable status.

[0039] In one optional implementation of this embodiment, if the return value is false, it indicates that the corresponding configuration item is in a non-writable state. In this case, the corresponding UI switch in the user interface control is grayed out and disabled.

[0040] If the return value for the writable state is false at this point, it indicates that the configuration item has been forcibly controlled by the underlying locks list (i.e., the lock list file) of Dconf and is in a non-writable state. At this time, the front-end logic will gray out (disable) the user interface control (such as the switch) and disable interaction.

[0041] If the return value is true, it indicates that the corresponding configuration item is writable. At this time, the corresponding UI switch in the user interface control remains available, and the current control value after the issued policy is read, and the UI display is refreshed.

[0042] If the return value of the writable state is true, it indicates that the configuration item is not subject to mandatory control. The UI switch in the corresponding user interface control will remain in a normal highlighted and available state, and the current control value after the issuance of the control policy will be retrieved to refresh the UI display interface.

[0043] Optionally, in response to the domain exit command, the domain management client calls the domain exit interface of the configuration management service process to perform atomic operations to delete the system-level overwrite configuration file and lock list file, and then performs the underlying configuration database update again to unlock the data.

[0044] Based on the strict priority characteristics of Dconf: Dconf lock list value > system-level overriding configuration file value > user-level configuration history value > system Gsettings default value, when a user device needs to leave domain management, the domain management client calls the USD process's exit interface, such as the ExitSecurity() interface. At this time, the USD process performs atomic operations to directly delete the system-level overriding configuration file and lock list file in the preset directory, such as deleting / etc / dconf / db / local.d / 99-security-config and / etc / dconf / db / local.d / locks / security-locks. After deletion, USD executes `sudo dconf update` again to update the Dconf database and release the data locks.

[0045] The front-end configuration interface is triggered again to identify the changes in the underlying configuration information and broadcast the native data change signal again. After receiving the broadcast native data change signal, the desktop component calls the writability query interface to query the writability status of the configuration items of the affected user interface controls and restores the non-writable status.

[0046] At this point, Gsettings is triggered again by the underlying change, broadcasting the changed signal to the desktop component once more. Upon receiving the signal, the desktop component calls g_settings_is_writable() again. Since the locked file has been deleted, the return value is true, restoring the previously locked, writable state.

[0047] By using Gsettings, historical values ​​of the control policies stored in the underlying configuration database before their issuance are automatically read and applied, the corresponding UI switches in the user interface controls are restored and refreshed to display the UI interface before the control policies were issued.

[0048] Since the first two high-priority control files have been deleted, Gsettings automatically reads the third-priority user-level configuration history values—that is, the user-defined historical values ​​retained before the control policy update was issued to the Dconf database—and applies them. Ultimately, the front-end UI not only automatically unfurls its grayed-out state but also accurately restores the personalized desktop interface set by the user before the control measures were implemented. It should be noted that although users are prohibited from modifying configuration values ​​while the Dconf database is locked, the personalized values ​​set by the user before the control measures were issued (i.e., user-level historical values) are still retained in the Dconf user database and are not deleted or overwritten, allowing for automatic rollback upon domain exit.

[0049] This embodiment generates a JSON-formatted capability set file when installing software packages on the desktop component. The USD daemon acts as the configuration management service process, ensuring the accuracy and completeness of the global capability set information. The global capability set is queried and policies are distributed through a preset interface on the system bus. The domain management client dynamically verifies the legality of policies based on the global capability set information. Simultaneously, the underlying Linux Dconf database is used, and the configuration management service process converts policies into a Dconf-recognizable format. The front-end uses the Gsettings interface and its native changed signal. After the underlying database is compiled, the front-end configuration interface is directly triggered to send a native data change signal. Upon receiving this signal, the desktop component calls a callback function to traverse the affected UI controls and uses the return value of the writability query interface to achieve adaptive UI rendering. When responding to a domain exit command, the domain management client calls the domain exit interface. The USD process performs an atomic operation to directly delete the overwrite configuration file and lock list file of the Dconf system and executes the database update command again, triggering the Gsettings broadcast changed signal again. This causes the UI of the controlled component to be re-queried as writable, and Gsettings automatically reads the historical configuration values ​​retained at the underlying level before the distribution of management policies to refresh the interface and restore the user's personalized configuration. By collaboratively writing system-level overriding configuration files and lock list files, the Dconf database achieves forced locking of desktop configurations, preventing low-privilege processes from bypassing or hijacking them. Meanwhile, Dconf's inherent priority logic provides a fundamental guarantee for forced configuration effectiveness. Custom inter-process communication signals are no longer sent via the system bus, significantly reducing coupling between desktop components and management services, decreasing system load, and mitigating authentication security risks that custom signals might pose. No hardcoding of management items supported by each component is required, achieving complete decoupling between policy distribution and desktop component versions. When components are added or upgraded, the management platform can automatically detect and adapt, improving system scalability and maintainability. A closed-loop management system is achieved based on the native Linux desktop infrastructure Dconf and Gsettings, without relying on additional custom protocols or middleware, ensuring high availability and compatibility of the underlying architecture. This allows cylindrical components to accurately distinguish between configuration value changes and writability changes, improving UI responsiveness and user experience. By leveraging the strict priority reading mechanism of the Dconf database, only a minimalist atomic file deletion operation is required when leaving the domain. This automatically unlocks the UI of the front-end interface and allows Gsettings to accurately retrieve the user's personalized historical data before the control measures were implemented, eliminating the need for complex and error-prone data backup and restore logic.

[0050] Example 3 Figure 3This is a schematic diagram of a desktop environment management and recovery device based on bottom-end-front-end native signals according to Embodiment 3 of the present invention. In this embodiment, the desktop environment management and recovery device based on bottom-end-front-end native signals includes: The capability set construction module 810 is used to generate structured capability set files in a preset directory during desktop component installation, use the configuration management service process to scan the preset directory, extract all structured capability set files to form global capability set information, and provide query services to the outside world through a preset interface; The configuration update module 820 is used to obtain the management policy to be issued by the domain management client, and to perform legality verification based on the global capability set information through the preset interface. After the verification is successful, the preset policy issuance interface is called, and the management policy to be issued is transformed into a Dconf database recognizable form by the configuration management service process to form the underlying configuration information and write it into the system-level overriding configuration file. At the same time, the configuration items that need to be forcibly managed are marked and written into the lock list file to update the underlying configuration database. The display update module 830 is used to trigger the front-end configuration interface to monitor the changes in the underlying data after the underlying configuration database is updated, and broadcast the native data change signal to the desktop component that has been bound to the configuration item identifier in advance. The desktop component calls the writability query interface to query the writability status of the corresponding configuration item and adaptively adjusts the UI display status of the user interface control.

[0051] This embodiment uses a capability set construction module to aggregate all capability sets into global capability set information and provide an external query interface. A configuration update module verifies the control policies to be issued and writes them to the Dconf database for compilation and update. A display update module adjusts the desktop display status based on the updated changes. By automatically generating and aggregating capability set files during component installation, the control end can dynamically know the actual policy range supported by the terminal, completely decoupling the control policies from the desktop component version. By directly converting policies into overwrite and lock files in the underlying database, a data-driven control issuance closed loop is achieved. Underlying data updates automatically trigger native data change signals in the front-end interface, and combined with front-end writability status queries, the desktop component can automatically perform forced graying and refreshing of the interface without listening to any custom inter-process communication signals, eliminating strong communication coupling between the control service and the desktop component, and improving system stability under high-concurrency control and abnormal scenarios.

[0052] The desktop environment management and recovery device based on bottom-front-end native signals provided in this embodiment of the invention can execute the desktop environment management and recovery method based on bottom-front-end native signals provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0053] Example 4 Figure 4 This is a structural diagram of an electronic device according to Embodiment 4 of the present invention. Figure 4 A block diagram is shown of an exemplary electronic device 12 suitable for implementing embodiments of the present invention. Figure 4 The electronic device 12 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0054] like Figure 4 As shown, the electronic device 12 is represented in the form of a general-purpose computing device. The components of the electronic device 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0055] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0056] Electronic device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by electronic device 12, including volatile and non-volatile media, removable and non-removable media.

[0057] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. Electronic device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (… Figure 4 Not shown; usually referred to as a "hard drive"). Although Figure 4 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0058] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0059] Electronic device 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), and with one or more devices that enable a user to interact with the electronic device 12 / server / computer, and / or with any device that enables the electronic device 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed through input / output (I / O) interface 22. Furthermore, electronic device 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20. Figure 4 As shown, network adapter 20 communicates with other modules of electronic device 12 via bus 18. It should be understood that, although... Figure 4 As not shown, other hardware and / or software modules may be used in conjunction with electronic device 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0060] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the desktop environment management and recovery method based on bottom-front-end native signals provided in the embodiments of the present invention.

[0061] Example 5 Embodiment 5 of the present invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the desktop environment management and recovery method based on bottom-front-end native signals as provided in the above embodiments.

[0062] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0063] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0064] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including, but not limited to, wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0065] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0066] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A desktop environment management and recovery method based on bottom-end-front-end native signals, characterized in that, include: S101 generates a structured capability set file in a preset directory during desktop component installation. It uses the configuration management service process to scan the preset directory, extract all structured capability set files to form global capability set information, and provides query services to the outside world through a preset interface. S102: Use the domain management client to obtain the management policy to be issued, and use the preset interface to verify its legality based on the global capability set information. After the verification is successful, call the preset policy issuance interface, use the configuration management service process to perform Dconf database-recognizable transformation of the management policy to be issued, form the underlying configuration information and write it into the system-level overriding configuration file, and at the same time write the configuration item that needs to be forcibly managed into the lock list file to update the underlying configuration database. S103 After the underlying configuration database is updated, the front-end configuration interface is triggered to monitor the changes in the underlying data and broadcast the native data change signal to the desktop components that have been bound to the configuration item identifier. The desktop components call the writability query interface to query the writability status of the corresponding configuration item and adaptively adjust the UI display status of the user interface controls.

2. The method according to claim 1, characterized in that, S101 includes: When installing software packages on desktop components, a structured capability set file describing the control support items is generated in a preset directory. The structured capability set file includes the controlled component name, the configuration items that support control, and the configuration item type. The USD daemon is started as a configuration management service process, scans the preset directory, extracts all structured capability set files and performs format verification, and integrates the verified structured capability set files to form global capability set information; The configuration management service process returns the file path of global capability set information through a preset query interface exposed by the system bus, which is then called by the domain management client to dynamically obtain global capability set information and query the management items supported by the current desktop environment.

3. The method according to claim 1, characterized in that, S102 includes: The domain management client calls the preset interface of the configuration management service process to obtain global capability set information, and performs dynamic queries to verify the legitimacy based on the management policy to be issued; After verification, the domain management client calls the policy distribution interface of the configuration management service process to transmit the management policy to be distributed to the configuration management service process. The configuration management service process converts the management policies to be issued into a format recognizable by the Dconf database, forms the underlying configuration information and writes it into the system-level overriding configuration file, and at the same time writes the key-value paths of the configuration items that need to be forcibly managed into the lock list file; The configuration management service process compiles the underlying configuration database, uses the front-end configuration interface to identify changes in the underlying configuration information, updates the underlying configuration database, and makes the system-level overwrite configuration files and lock list files effective.

4. The method according to claim 3, characterized in that, S103 includes: After the underlying configuration database is compiled, the front-end configuration interface is triggered to recognize the changes in the underlying configuration information, forming a native data change signal, which is then broadcast to the desktop components that have been pre-bound with the corresponding configuration item identifiers, and no longer sends custom inter-process communication signals. After receiving the broadcast native data change signal, the desktop component calls the callback function of the native data change signal and iterates through the user interface controls in the desktop component that are affected by the configuration item identifier. The desktop component calls the writability query interface to query the writability status of the configuration items of the affected user interface controls, and adjusts the display status of the user interface controls based on the return value.

5. The method according to claim 4, characterized in that, The step of adjusting the display state of user interface controls based on the return value includes: If the return value is false, it indicates that the corresponding configuration item is not writable. In this case, the corresponding UI switch in the user interface control will be grayed out and disabled. If the return value is true, it indicates that the corresponding configuration item is writable. At this time, the corresponding UI switch in the user interface control remains available, and the current control value after the issued policy is read, and the UI display is refreshed.

6. The method according to claim 4, characterized in that, The method further includes: In response to the domain exit command, the domain management client calls the domain exit interface of the configuration management service process to perform atomic operations to delete the system-level overwrite configuration file and lock list file, and then performs the underlying configuration database update again to unlock the data lock; The front-end configuration interface is triggered again to identify the changes in the underlying configuration information and broadcast the native data change signal again. After the desktop component receives the broadcast native data change signal, it calls the writability query interface to query the writability status of the configuration items of the affected user interface controls and restores the non-writable status. By using Gsettings, historical values ​​of the control policies stored in the underlying configuration database before their issuance are automatically read and applied, the corresponding UI switches in the user interface controls are restored and refreshed to display the UI interface before the control policies were issued.

7. The method according to claim 1, characterized in that, The method further includes: The structured capability set file is a JSON format file, which includes the names of the controlled components that support management, the keys of the configuration items, and their data types; The underlying configuration database is the Dconf database of the Linux system; The front-end configuration interface is the Gsettings interface, and the native data change signal is the native changed signal built into Gsettings.

8. A desktop environment management and recovery device based on bottom-end-front-end native signals, used to implement the desktop environment management and recovery method based on bottom-end-front-end native signals as described in any one of claims 1-7, characterized in that, include: The capability set construction module is used to generate structured capability set files in a preset directory when desktop components are installed. It uses the configuration management service process to scan the preset directory, extract all structured capability set files to form global capability set information, and provides query services to the outside world through a preset interface. The configuration update module is used to obtain the management policy to be issued by the domain management client, and to perform legality verification based on the global capability set information through the preset interface. After the verification is successful, the preset policy issuance interface is called. The configuration management service process performs a Dconf database-recognizable transformation on the management policy to be issued, forms the underlying configuration information and writes it into the system-level overriding configuration file. At the same time, the configuration items that need to be forcibly managed are marked and written into the lock list file to update the underlying configuration database. The display update module is used to trigger the front-end configuration interface to monitor the changes in the underlying data after the underlying configuration database is updated, and broadcast the native data change signal to the desktop components that have been bound to the configuration item identifier in advance. The desktop components call the writability query interface to query the writability status of the corresponding configuration item and adaptively adjust the UI display status of the user interface controls.

9. An electronic device, characterized in that, The electronic device includes: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the desktop environment management and recovery method based on low-level-front-end native signals as described in any one of claims 1-7.

10. A storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the desktop environment management and recovery method based on low-level-front-end native signals as described in any one of claims 1-7.

Images