Message notification architecture and management method for a Linux desktop operating system
By introducing a communication bus registration mechanism in the Linux desktop operating system, the notification server and client are decoupled, solving the problems of parallel access and scalability of multiple clients in the notification system, and improving the stability and flexibility of the system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- KYLIN CORP
- Filing Date
- 2026-05-19
- Publication Date
- 2026-06-19
Smart Images
Figure CN122240361A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of system notification technology, specifically providing a message notification architecture and management method for a Linux desktop operating system. Background Technology
[0002] With the continuous development of desktop operating systems, system notifications have become one of the most important basic services in desktop operating systems. In Linux-based desktop operating systems such as UKUI, GNOME, and KDE, the notification system is typically responsible for uniformly receiving notification requests from different applications and system modules and delivering the notification information to the user for processing.
[0003] However, in the design and implementation of existing notification systems, there is a common problem of high coupling between the notification server and the notification display module. Specifically, most notification services in existing desktop environments adopt an integrated implementation approach with a single service process: this process is not only responsible for receiving and managing notification messages, but also directly undertakes the display and interaction logic of the notifications. This integrated design tightly binds the notification display method to the server implementation. During operation, the notification server can only send notification messages to a single fixed notification display module (such as GNOME Shell's notification-daemon, KDE Plasma's plasma-workspace, etc.), which cannot support multiple notification clients receiving and processing notification information simultaneously, making it difficult to adapt to scenarios where multiple terminals, multiple display strategies, or auxiliary functions run in parallel.
[0004] Furthermore, under the above architecture, a strong coupling exists between the notification server and the notification display module. The notification display module cannot be dynamically replaced or independently deployed during system operation, nor does it support third-party notification clients accessing the notification system without modifying the server, significantly limiting system scalability. Simultaneously, since the notification display module typically does not require explicit registration to access the notification service, the notification server defaults to sending notification messages to pre-bound display objects, lacking a dynamic registration, deregistration, and state management mechanism for notification clients. This makes flexible scheduling and management in scenarios with multiple notification clients impossible.
[0005] Furthermore, because the notification server and notification display logic are tightly coupled, introducing new notification display methods, adapting to different terminal forms, or adjusting notification interaction logic often requires modifying, recompiling, and deploying the notification service process. This increases the complexity of system maintenance and version upgrades, hindering the long-term evolution of the notification system. Regarding system stability, the existing architecture lacks a clear lifecycle management mechanism between the notification service and the notification display module. If the notification display module or service process exits abnormally, its integrated notification receiving and display functions will be interrupted, potentially leading to lost or unprocessed notification messages, impacting system stability.
[0006] In summary, existing Linux desktop notification systems, with their highly coupled architecture between the notification server and the notification display module, suffer from several technical shortcomings, including a lack of parallel access capabilities for multiple clients, insufficient dynamic scalability, a lack of a unified client registration and management mechanism, high system maintenance and upgrade costs, and inadequate system stability and fault tolerance. Therefore, it is necessary to propose a new notification service architecture. By introducing a registration mechanism between the notification service and notification clients, the architecture decouples the notification server from the notification display logic. This allows the notification server to focus on the unified reception and distribution of notification messages, while multiple independently registerable notification clients handle the display and processing of notifications, thereby improving the scalability, flexibility, and system stability of the notification system in multi-client scenarios. Summary of the Invention
[0007] To overcome the above-mentioned shortcomings, this invention is proposed to provide solutions to the technical problems of high coupling between the notification server and the notification display module, lack of support for multiple notification clients, and insufficient runtime scalability in existing Linux desktop notification systems.
[0008] In a first aspect, the present invention provides a message notification architecture for a Linux desktop operating system, including a notification server and at least one notification client. The notification server and each notification client interact via a communication bus. The notification server is used to receive notification requests from applications, system components, or background services, and to uniformly manage and distribute notification messages. The notification client is used to receive notification messages from the notification server and to display or process the notification messages.
[0009] Furthermore, the notification server registers a first notification interface and a second management interface with the outside world through the communication bus. The first notification interface is used to receive notification messages sent by the application, and the second management interface is used to provide registration and deregistration services for notification clients.
[0010] Furthermore, the first notification interface is compatible with the org.freedesktop.Notifications interface specification, and the second management interface can be implemented using org.ukui.NotificationServer.
[0011] Furthermore, a notification client registry is maintained in the notification server to record the identifiers of currently registered notification clients, and the distribution strategy for notification messages is determined based on the registration status of the notification clients.
[0012] Furthermore, in response to a registration request initiated by a notification client, the notification server records the corresponding notification client identifier in the registry after successful registration; in response to an abnormal exit or interruption of the communication connection by a notification client, the notification server listens for changes in the registration status of the corresponding notification client through the communication bus and automatically removes the notification client from the notification client registry.
[0013] Furthermore, when the notification server receives a new notification message, if there is a registered notification client, the notification server will broadcast the notification message to the client; if there is no registered client, the notification message will be cached.
[0014] Furthermore, during runtime, the notification client initiates a registration request to the notification server through the second communication interface. After successful registration, the notification client registers a notification receiving interface on a preset object path through the communication bus to receive notification messages sent by the notification server. After receiving the notification message, the notification client displays or processes the content of the notification message according to a preset display strategy or interaction logic.
[0015] Secondly, this invention provides a message notification management method for a Linux desktop operating system, applied to a notification server, comprising the following steps: A1: In response to the operating system startup, notify the server process to start and register the first notification interface and the second management interface with the communication bus; A2: The notification server initializes the notification client registry and notification message cache for subsequent client management and message caching. A3: The notification server enters the running state, listening for notification requests from applications, system components, or background services, as well as registration requests, deregistration requests, and expiration events from notification clients; A4: In response to receiving a notification request, the notification server determines whether a registered notification client exists in the notification client registry. If a registered client exists, the notification message is distributed to the notification client via the communication bus. If no registered client exists, the notification message is stored in the notification message cache. In response to a registration request from a notification client, the notification client is added to the notification client registration list. After the notification client registration is completed, it is determined whether there is a notification message in the notification message buffer. If there is, the notification message is distributed to the notification client through the communication bus. In response to a notification client's deregistration request or invalidation event, the corresponding notification client is removed from the notification client registration list; A5: When the operating system shuts down or the server is notified to stop running, perform resource release and state cleanup operations.
[0016] Thirdly, this invention provides a message notification management method for a Linux desktop operating system, applied to a notification client, comprising the following steps: B1: Notify the client to start and register the notification receiving interface with the communication bus; B2: Notify the client to listen for the availability status of the second management interface on the notification server; B3: After detecting that the notification server is available, a registration request is sent to the notification server through the second management interface; B4: After successful registration, notify the client to listen for notification messages from the notification server. If registration fails, continue to listen for the status of the notification server and re-initiate the registration request when the conditions are met. B5: Upon receiving a notification message, instruct the client to display or process the notification message according to a preset display strategy or interaction logic; B6: When the client is notified to exit runtime, a deregistration request is sent to the notification server through the second management interface to complete the deregistration.
[0017] The working principle and beneficial effects of this invention: In implementing the technical solution of this invention, by introducing a registration and management mechanism based on a communication bus between the notification server and the notification client, the structural decoupling of the notification service and the display logic is achieved, allowing both to evolve independently; it supports parallel access and simultaneous operation of multiple clients, meeting the needs of multi-screen and multi-strategy scenarios; it ensures that notification messages are not lost through caching and resending mechanisms; it effectively isolates faults by automatically sensing the client status and promptly cleaning up failed connections, significantly improving the stability and continuous service capability of the system; at the same time, new clients can be independently developed and deployed according to specifications without modifying the server, greatly reducing the system expansion and maintenance costs. Attached Figure Description
[0018] The disclosure of this invention will become more readily understood with reference to the accompanying drawings. It will be readily understood by those skilled in the art that these drawings are for illustrative purposes only and are not intended to limit the scope of protection of this invention. Furthermore, similar numbers in the drawings are used to denote similar components, wherein: Figure 1 This is a schematic diagram of the message notification architecture of a Linux desktop operating system according to the present invention; Figure 2 This is a flowchart illustrating the main steps of the message notification management method applied to the notification server in this invention. Figure 3 This is a flowchart illustrating the main steps of the message notification management method applied to the notification client in this invention. Detailed Implementation
[0019] Some embodiments of the present invention will now be described with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are merely illustrative of the technical principles of the present invention and are not intended to limit the scope of protection of the present invention.
[0020] Example 1 Figure 1 This is a schematic diagram of the message notification architecture of a Linux desktop operating system according to the present invention. Figure 1 As shown, the message notification architecture of a Linux desktop operating system in this embodiment includes a notification server and at least one notification client. The notification server and each notification client interact with each other via a communication bus, which is preferably a D-Bus message bus.
[0021] 1. Notify the server The notification server is used to receive notification requests from applications, system components, or background services, and to manage and distribute notification messages in a unified manner. It does not participate in any interface rendering or interactive logic related to the display of notification messages.
[0022] In one implementation, the notification server registers a first notification interface and a second management interface externally via a communication bus. The first notification interface receives notification messages sent by applications, and the second management interface provides registration and deregistration services for notification clients. The first notification interface is compatible with the org.freedesktop.Notifications interface specification, and the second management interface can be implemented using org.ukui.NotificationServer.
[0023] In one implementation, to support multiple notification clients receiving notification messages in parallel, a notification client registry is maintained in the notification server to record the identifiers of currently registered notification clients and determine the notification message distribution strategy based on the registration status. Simultaneously, dynamic registration and deregistration of notification clients during system operation are supported. When a notification client actively deregisters or experiences an abnormal exit, the notification server can promptly update the registry status, thereby achieving dynamic management of notification clients.
[0024] Specifically, in response to a registration request initiated by a notification client, the notification server records the corresponding notification client identifier in the registry after successful registration. In response to an abnormal exit or interruption of the communication connection by a notification client, the notification server can detect the change in the registration status of the corresponding notification client through the communication bus and automatically remove the notification client from the notification client registry without affecting the continued receipt of notification messages by other registered notification clients.
[0025] In one implementation, when the notification server receives a new notification message, it distributes the notification message to one or more registered notification clients based on the notification client registry. Specifically, when a registered notification client exists, the notification server broadcasts the notification message to that client; when no registered client exists, the notification message is cached.
[0026] When the notification server distributes notification messages to multiple notification clients, it adopts independent sending strategies to avoid the overall notification distribution process being blocked due to the failure of a single notification client, thereby improving the fault tolerance and continuous service capabilities in abnormal scenarios.
[0027] 2. Notify the client The notification client is used to receive notification messages from the notification server and to display or process the notification messages without needing to know the source of the notification messages or the internal implementation of the notification server.
[0028] In one implementation, the notification client initiates a registration request to the notification server at runtime via an inter-process communication interface. After successful registration, the notification client registers a notification receiving interface on a preset object path via the communication bus to receive notification messages sent by the notification server. Upon receiving the notification message, the notification client displays or processes the message content according to a preset display strategy or interaction logic.
[0029] In one implementation, the notification message may be transmitted using a uniform data structure, such as the PopupNotification structure, but is not limited to this specific form.
[0030] In this embodiment, different notification clients are independent of each other, and the notification server does not limit the specific display method of the notification message, thereby allowing different notification clients to process the notification in different forms according to their own operating environment or functional positioning.
[0031] Figure 1In this code, Notification Server represents the notification server, which includes two implementations: a first notification interface and a second management interface. Notification Client represents the notification client. libukui-notification is a development library that encapsulates the necessary low-level operations such as registration and deregistration for direct use by developers. Notification-ukcc-plugin is a specific application of this library, serving as a plugin for the system control center and providing users with a graphical interface to configure notification parameters. org.ukui.NotificationClient is the language for external communication. Notification clients register with the server and receive messages through this D-Bus interface. It standardizes the client's identity.
[0032] This embodiment proposes a message notification architecture for a Linux desktop operating system. By introducing a clear registration and management mechanism between the notification server and the notification client, the functional boundaries between the two are clearly defined. This allows the notification server to focus on receiving, managing, and distributing notification messages, while the specific display and interaction processing of notifications are handled by independently deployable notification clients. This creates a loose coupling between the notification server and the notification display logic, thereby preventing changes in notification display requirements from affecting the stable operation of the notification server and providing infrastructure support for the parallel access of multiple notification clients.
[0033] Example 2 Figure 2 This is a schematic diagram illustrating the main steps of the message notification management method applied to the notification server in this invention. For example... Figure 2 As shown in the figure, this embodiment proposes a message notification management method for a Linux desktop operating system, which is applied to a notification server and mainly includes the following steps A1-A5.
[0034] Step A1: In response to the operating system startup, notify the server process to start and register the first notification interface and the second management interface with the communication bus; Step A2: The server initializes the client registry and notification message cache for subsequent client management and message caching. Step A3: The notification server enters the running state, listening for notification requests from applications, system components, or background services, as well as registration, deregistration, or expiration events from notification clients; Step A4: In response to receiving a notification request, the notification server determines whether a registered notification client exists in the notification client registry. If a registered client exists, the notification message is distributed to the notification client via the communication bus. If no registered client exists, the notification message is stored in the notification message cache. In response to a registration request from a notification client, the notification client is added to the notification client registration list. After the notification client registration is completed, it is determined whether there is a notification message in the notification message buffer. If there is, the notification message is distributed to the notification client through the communication bus. In response to a notification client's deregistration request or failure event, the corresponding notification client is removed from the notification client registration list.
[0035] Step A5: When the operating system shuts down or the server is notified to stop running, perform resource release and state cleanup operations.
[0036] Based on steps A1-A5 above, the startup and operation process of the notification server is implemented.
[0037] Example 3 Figure 3 This is a schematic diagram illustrating the main steps of the message notification management method applied to the notification client in this invention. For example... Figure 3 As shown in the figure, this embodiment proposes a message notification management method for a Linux desktop operating system, which is applied to a notification client and mainly includes the following steps B1-B6.
[0038] Step B1: Notify the client to start and register the notification receiving interface with the communication bus; Step B2: Notify the client to listen for the availability status of the second management interface on the notification server; Step B3: After detecting that the notification server is available, initiate a registration request to the notification server through the second management interface; Step B4: After successful registration, notify the client to listen for notification messages from the notification server. If registration fails, continue to listen for the status of the notification server and re-initiate the registration request when the conditions are met. Step B5: After receiving the notification message, instruct the client to display or process the notification message according to the preset display strategy or interaction logic.
[0039] Step B6: Notify the client to exit runtime, and send a deregistration request to the notification server through the second management interface to complete the deregistration.
[0040] Based on steps B1-B6 above, the process of listening to, registering / unregistering, receiving and processing notifications on the client is implemented.
[0041] It should be noted that although the steps in the above embodiments are described in a specific order, those skilled in the art will understand that in order to achieve the effects of the present invention, different steps do not necessarily have to be executed in such an order. They can be executed simultaneously (in parallel) or in other orders, and these variations are all within the scope of protection of the present invention.
[0042] The present invention has the following advantages: 1. Existing notification systems typically only support a single, fixed notification display module. During operation, the notification server cannot simultaneously distribute notification messages to multiple clients, nor can it differentiate the processing needs of different clients, making it difficult to adapt to application scenarios with multiple display strategies or multiple auxiliary functions running in parallel. This invention solves the problem of parallel access by introducing a notification client registration mechanism, enabling the notification server to uniformly manage multiple notification clients and distribute notification messages to one or more registered clients.
[0043] 2. In existing technologies, the notification server typically handles both notification reception and display, resulting in a tight binding between the notification display method and the server implementation, and a lack of runtime scalability. This invention addresses this by constructing a message bus-based client registration and deregistration mechanism. This allows the notification server to focus solely on receiving, managing, and distributing notification messages, while delegating the actual display and interaction processing to independently deployable notification clients. This decouples the notification service from the display logic and supports dynamic plugging and unplugging of notification clients during system operation.
[0044] 3. In traditional notification systems, the display logic is deeply coupled with the server-side. Introducing any new display method or strategy requires modifications to the server, increasing the complexity of system maintenance and upgrades. This invention decentralizes notification display capabilities to a separate notification client, allowing the client to evolve independently without affecting the notification server, thereby reducing the overall cost of expanding, upgrading, and maintaining the notification system.
[0045] 4. In existing notification systems, an abnormal exit of the notification display module may cause the entire notification service to become unavailable or notification messages to be lost. This invention, based on a message bus communication mechanism, manages the lifecycle of the notification client. When an abnormal exit or disconnection of the communication connection is detected, the notification server can automatically update the client's registration status and continue to distribute notification messages to other valid clients, thereby improving the stability and reliability of the notification system under abnormal scenarios.
[0046] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after such changes or substitutions will all fall within the scope of protection of the present invention.
Claims
1. A message notification architecture for a Linux desktop operating system, characterized by, It includes a notification server and at least one notification client. The notification server and each notification client interact with each other via a communication bus. The notification server is used to receive notification requests from applications, system components or background services, and to uniformly manage and distribute notification messages. The notification client is used to receive notification messages from the notification server and to display or process the notification messages.
2. The message notification architecture of a Linux desktop operating system according to claim 1, wherein, The notification server registers a first notification interface and a second management interface with the outside world through the communication bus. The first notification interface is used to receive notification messages sent by the application, and the second management interface is used to provide registration and deregistration services for notification clients.
3. The message notification architecture of a Linux desktop operating system according to claim 2, wherein, The first notification interface is compatible with the org.freedesktop.Notifications interface specification, while the second management interface uses org.ukui.NotificationServer as its implementation.
4. The message notification architecture of a Linux desktop operating system according to claim 1, wherein, The notification server maintains a registration form for notification clients to record the identifiers of currently registered notification clients and determines the distribution strategy for notification messages based on the registration status of the notification clients.
5. The message notification architecture of a Linux desktop operating system according to claim 4, wherein, In response to the registration request initiated by the client, the server records the corresponding client identifier in the registry after successful registration. In response to an abnormal exit or communication connection interruption of a notification client, the notification server monitors the registration status changes of the corresponding notification client through the communication bus and automatically removes the notification client from the notification client registry.
6. The message notification architecture of a Linux desktop operating system according to claim 4, characterized in that, When the notification server receives a new notification message, if there is a registered notification client, the notification server will broadcast the notification message to the client; if there is no registered client, the notification message will be cached.
7. The message notification architecture of a Linux desktop operating system according to claim 1, characterized in that, When the notification client is running, it initiates a registration request to the notification server through the second communication interface. After successful registration, the notification client registers a notification receiving interface on a preset object path through the communication bus to receive notification messages sent by the notification server. After receiving the notification message, the notification client displays or processes the content of the notification message according to a preset display strategy or interaction logic.
8. A message notification management method for a Linux desktop operating system, characterized in that, When applied to a notification server, the following steps are included: A1: In response to the operating system startup, notify the server process to start and register the first notification interface and the second management interface with the communication bus; A2: The notification server initializes the notification client registry and notification message cache for subsequent client management and message caching. A3: The notification server enters the running state, listening for notification requests from applications, system components, or background services, as well as registration requests, deregistration requests, and expiration events from notification clients; A4: In response to receiving a notification request, the notification server determines whether a registered notification client exists in the notification client registry. If a registered client exists, the notification message is distributed to the notification client via the communication bus. If no registered client exists, the notification message is stored in the notification message cache. In response to a registration request from a notification client, the notification client is added to the notification client registration list. After the notification client registration is completed, it is determined whether there is a notification message in the notification message buffer. If there is, the notification message is distributed to the notification client through the communication bus. In response to a notification client's deregistration request or failure event, the corresponding notification client is removed from the notification client registration list.
9. A message notification management method for a Linux desktop operating system according to claim 8, characterized in that, It also includes step A5: when the operating system shuts down or notifies the server to stop running, perform resource release and state cleanup operations.
10. A message notification management method for a Linux desktop operating system, characterized in that, When applied to a notification client, the following steps are included: B1: Notify the client to start and register the notification receiving interface with the communication bus; B2: Notify the client to listen for the availability status of the second management interface on the notification server; B3: After detecting that the notification server is available, a registration request is sent to the notification server through the second management interface; B4: After successful registration, notify the client to listen for notification messages from the notification server. If registration fails, continue to listen for the status of the notification server and re-initiate the registration request when the conditions are met. B5: Upon receiving a notification message, instruct the client to display or process the notification message according to a preset display strategy or interaction logic; B6: When the client is notified to exit runtime, a deregistration request is sent to the notification server through the second management interface to complete the deregistration.