Event-Driven Architecture-Based Terminal Graphical Interface Display System and Method

Abstract

This invention discloses a terminal graphical user interface system and method based on an event-driven architecture, relating to the field of terminal interface display technology. It includes: an application management layer establishing a connection between the Qt event loop and the underlying rendering engine; a rendering scheduling layer aggregating rendering requests into a unified output at a fixed frequency through atomic variable marking and a timed batch rendering mechanism; a control system layer constructing a layered dynamic control architecture based on the CView base class; an event handling layer realizing real-time response and distribution of input events through an asynchronous input monitoring thread and a signal-slot mechanism; and a platform adaptation layer encapsulating the differences in terminal characteristics across different operating systems. By aggregating scattered rendering requests into a unified output at a fixed frequency, encapsulating and integrating the Qt object tree through the CView base class, and implementing asynchronous input monitoring and signal-slot mechanisms, automatic management of controls and rendering resources is achieved, overcoming the performance bottleneck of real-time rendering, and ensuring consistency in multilingual text display.

Description

Technical Field

[0001] This invention relates to the field of terminal interface display technology, and in particular to a terminal graphical interface display system and method based on an event-driven architecture. Background Technology

[0002] Current graphical user interface (GUI) rendering technologies primarily rely on traditional character-based interface libraries, such as third-party libraries like notcurses. These typically employ direct character drawing, lacking efficient rendering request aggregation and delayed batch execution mechanisms, resulting in low rendering efficiency when handling complex GUI elements. notcurses' real-time rendering model leads to a linear correlation between the number of rendering calls and control update frequency. When the notcurses_render() function is called more than 20 times per second, terminal emulators such as xterm and Windows Terminal exhibit noticeable input latency and screen flickering due to excessive ANSI escape sequences being parsed. Particularly in moderately complex TUI applications containing more than 50 dynamic controls, input latency and screen flickering significantly hinder user operation. Furthermore, the numerous dynamic control APIs require developers to have a high level of understanding of underlying details, making it difficult to develop GUIs with efficient rendering capabilities. Summary of the Invention

[0003] This invention provides a terminal graphical interface display system and method based on an event-driven architecture to solve the technical problems of low rendering efficiency and high development difficulty of complex terminal graphical interfaces with multiple controls.

[0004] In a first aspect, embodiments of the present invention provide a terminal graphical user interface display system based on an event-driven architecture, comprising: The application management layer is used to initialize the terminal's graphical user interface environment and establish the connection between the Qt event loop and the underlying rendering engine. It manages the lifecycle of applications on the terminal and provides an object-oriented programming interface. The rendering scheduling layer is used to receive rendering requests from dynamic controls in the graphical interface and respond to the requests by performing aggregated and batch delayed graphical interface rendering. The control system layer is used to derive dynamic controls from multiple terminal graphical interfaces and construct graphical user interfaces. In response to interactive events generated by user operations on the graphical interface, it sends corresponding rendering requests to the rendering scheduling layer. The event handling layer is used to capture terminal input events through asynchronous listening and dispatch the input events to the corresponding dynamic controls in the graphical interface; The platform adaptation layer is used to encapsulate the differences in terminal characteristics across different operating system platforms and provide the application management layer with operation interfaces for obtaining the size of the terminal's graphical interface, managing colors, and processing system signals.

[0005] Secondly, embodiments of the present invention provide a terminal graphical interface display method based on an event-driven architecture, including: S101, execute system initialization, create an application management object instance, initialize the core engine and standard rendering plane, and configure the rendering timer and asynchronous input listening thread; S102, Instantiate multiple dynamic controls based on the same base class in the terminal graphical interface, and establish the parent-child hierarchical relationship between each dynamic control through the constructor to form a control relationship description tree, so as to construct the terminal graphical interface; S103, responding to user operation and modifying the rendering request flag, when the rendering request flag of any dynamic control changes, the corresponding atomic variable is set to true, but terminal rendering is not performed immediately; S104: Use the rendering timer to check each rendering request flag in each checking cycle. If any rendering request flag is true, perform a batch rendering screen redraw operation, draw all the content of the current graphical interface according to the control relationship description tree, and reset the rendering request flag to false. S105 uses an asynchronous input listening thread to capture terminal input events in a non-blocking loop, distinguishes between keyboard input events and mouse input events, encapsulates them into input events, sends a Qt signal to the main UI thread, and then uses a signal slot to dispatch to the slot function of the corresponding target dynamic control in the control relationship description tree, triggering the state change of the dynamic control and modifying the value of the rendering request flag. S106, during system initialization, obtaining the current display area size of different terminals, or processing system signals, calls the encapsulated interface provided by the terminal-specific differences of different operating system platforms to obtain the current display area size of the terminal, perform color management, and process system signals.

[0006] This invention provides a terminal graphical user interface display system and method based on an event-driven architecture. The system constructs a layered architecture including an application management layer, a rendering scheduling layer, a control system layer, an event handling layer, and a platform adaptation layer. The rendering scheduling layer implements the aggregation and delayed batch execution of rendering requests through atomic variable marking and timer checks. The control system layer provides an object-oriented interface construction method through dynamic controls inherited from the same base class and a parent-child relationship management mechanism. The event handling layer implements asynchronous input listening and distribution through independent threads and a signal-slot mechanism. The platform adaptation layer encapsulates the differences in terminal characteristics of different operating systems through a unified interface and also integrates a text processing layer that performs intelligent width calculation, omission, and line break processing for Unicode text, thereby constructing a complete event-driven graphical user interface display system in the terminal environment. By using atomic variable marking and a timed batch rendering mechanism in the rendering scheduling layer, millisecond-level scattered rendering requests are aggregated into a unified output at a fixed frequency, significantly reducing the ANSI escape sequence parsing burden on the terminal emulator. The CView base class encapsulates the ncplane rendering plane and integrates a bidirectional mapping between the Qt object tree and the notcurses plane hierarchy, realizing automatic synchronization management of control lifecycle and rendering resources. Through precise width calculation and intelligent layout of Unicode monospace characters in the text processing layer, consistent text display in multilingual environments such as Chinese, Japanese, and Korean is ensured. By combining asynchronous input monitoring threads with the signal-slot mechanism, real-time response to user input is achieved without blocking interface rendering. Through unified encapsulation of the characteristics of different operating system terminals, consistent behavior of the application on different platforms is ensured. Attached Figure Description

[0007] 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 schematic diagram of the structure of a terminal graphical interface display system based on an event-driven architecture, as described in Embodiment 1 of the present invention. Figure 2 This is a flowchart of a terminal graphical interface display method based on an event-driven architecture, as described in Embodiment 2 of the present invention. Detailed Implementation

[0008] 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.

[0009] Example 1 Figure 1 This is a schematic diagram of the structure of a terminal graphical interface display system based on an event-driven architecture as described in Embodiment 1 of the present invention, specifically including: The application management layer initializes the terminal's graphical user interface environment and establishes the connection between the Qt event loop and the underlying rendering engine. It manages the lifecycle of applications on the terminal and provides an object-oriented programming interface. As the entry point for interaction between the operating system and users / developers, the application management layer is implemented by the QCoreApplication class, which inherits from the Qt framework. It encapsulates a notcurses core instance and a standard rendering plane, and is responsible for managing the global lifecycle of terminal applications.

[0010] During system initialization, a CApplication instance is created to initialize the terminal's graphical user interface application. First, the `notcurses_init()` function provided by the `notcurses` library is called to initialize the `notcurses` core instance, which serves as the underlying rendering engine. This engine is responsible for converting high-level drawing instructions into ANSI escape sequences recognizable by the terminal. Then, the `notcurses_stdplane()` function obtains the standard rendering plane as the root-level drawing canvas, and all subsequent UI elements are composited and rendered on this plane. Furthermore, CApplication establishes an input / output connection channel between Qt's signal-slot mechanism and the underlying `notcurses` engine. The Qt event loop handles high-level events such as timer events and signal-slot dispatch, while the `notcurses` engine handles low-level terminal control. The two collaborate through the application management layer. Simultaneously, application-level settings are encapsulated and object-oriented programming interfaces are provided, including `setApplicationDisplayName()` for setting the application name, `set_palette()` for configuring the global color scheme, and `set_minimum_size()` for setting the terminal's minimum size constraint, enabling configuration of the application's front-end display parameters, such as color and size.

[0011] The rendering scheduling layer receives rendering requests from dynamic controls in the graphical user interface (GUI) and responds to these requests by performing aggregated and batch-delayed GUI rendering. The rendering scheduling layer overcomes the performance bottleneck of real-time rendering through a three-stage processing model: rendering request marking, marking delay checks, and batch rendering execution. This model includes a first atomic variable, a second atomic variable, and a rendering timer. The first atomic variable, which can be `atomic_bool_render`, marks the status of update rendering requests triggered by updates to dynamic controls. The second atomic variable, which can be `atomic_bool_refresh`, marks the status of refresh rendering requests triggered by changes in the size of the GUI. The rendering timer triggers checks at fixed intervals.

[0012] Specifically, the rendering scheduling layer also includes: The request flag module is used to mark update rendering requests and refresh rendering requests due to size changes of dynamic controls using a first atomic variable and a second atomic variable, respectively. Two boolean atomic variables are used as state flags. The first atomic variable marks update rendering requests caused by state updates of dynamic controls, such as text changes or position movements. When any dynamic control, such as a text display control or input box control, undergoes a state change (e.g., text content update, cursor position movement, or size adjustment), the first atomic variable is set to true by calling CApplication::render(). The second atomic variable marks refresh rendering requests caused by changes in the terminal window size. When a change in terminal size is detected, such as when the user resizes the terminal window, CApplication::refresh() is called to set the second atomic variable to true, indicating that a full interface refresh and redraw is needed, rather than immediately initiating rendering.

[0013] The timed check module is used to check the state of the first and second atomic variables at a preset period using a rendering timer. During CApplication initialization, a fixed-period rendering timer is created synchronously. This timer periodically triggers a check task to examine the state (value) of the first and second atomic variables at the preset period to confirm whether there are any pending rendering requests. If both atomic variables are false, the rendering cycle is skipped and no screen operations are performed. If either atomic variable is true, a batch rendering process is triggered. For example, the rendering timer can be a QTimer with a preset period of 50ms. This ensures that multiple control updates occurring within a very short time (e.g., within a 50ms cycle) generate only one marking operation, rather than multiple rendering calls.

[0014] The batch rendering module triggers a unified batch rendering redraw operation on the terminal's graphical interface when the timer check module detects an pending rendering request. After redrawing, the first and second atomic variables are reset. In each trigger cycle of the timer, when any atomic variable is found to be true, it indicates an pending rendering request. At this point, a unified batch rendering redraw operation is performed to update the graphical interface. For example, first, the `ncplane_erase()` function is called to clear all content on the standard rendering plane, ensuring that the current rendering is not affected by historical rendering residues. Then, all visible dynamic controls (class instances) derived from the `CView` base class are traversed, and the `paint()` virtual function overridden by each control is called sequentially to write the control's character content, borders, background, and other drawing instructions to their respective associated `ncplane` planes. Finally, the `notcurses_render()` function is called to output all the aggregated plane content as a complete frame of data to the terminal's graphical interface at once. Finally, after rendering is complete, the values ​​of both atomic variables are reset to false, awaiting the next cycle check. By aggregating high-frequency, discrete rendering calls occurring at the millisecond level into batch rendering operations with a fixed period (the period preset by the timer), the burden on the terminal emulator to parse ANSI escape sequences is reduced, thereby eliminating flickering and stuttering issues when there are multiple dynamic controls.

[0015] The control system layer is used to derive dynamic controls from multiple terminal graphical interfaces and construct the graphical user interface. Responding to interactive events generated by user actions on the graphical interface, it sends corresponding rendering requests to the rendering scheduling layer. The control system layer adopts a layered architecture based on the CView base class, inheriting from QObject. It also encapsulates an instance of the ncplane rendering plane from the notcurses library, implementing a bidirectional mapping between the Qt object system and the notcurses rendering system. It natively supports Qt meta-objects (including features such as signals and slots, property reflection, etc.) to control the hierarchical relationship between parent and child dynamic controls, and achieves cross-dynamic control event communication through the signals and slots of Qt meta-objects.

[0016] Specifically, the control system layer also includes: The parent-child relationship management module automatically establishes and maintains the parent-child hierarchy and layout dependencies between dynamic controls based on the parent control parameter passed to the CView base class during dynamic control instantiation. The CView constructor receives a parent control pointer parameter and automatically maintains the parent-child relationship accordingly. The child control's ncplane is created using the parent control's ncplane as its parent plane, automatically forming a control relationship description tree through the parentRoot mechanism. If the passed parent control pointer is null, the created ncplane is used as a child plane of the standard rendering plane; if the passed parent control pointer is not null, it is used as a child plane of the parent control's ncplane. Changes in the parent control's size, show / hide status, and destruction operations are automatically propagated to the child controls, reducing the complexity of graphical interface composition and resource management.

[0017] The layout calculation module is used to adapt the size of child dynamic controls to the size of their parent dynamic controls via member functions, or to center child dynamic controls in the terminal's graphical interface via member functions. The CView base class provides the `maxisizeof_parent()` member function, which obtains the size of the parent control's `ncplane`, subtracts the margins and borders, and then calls `ncplane_resize()` to adjust its own plane size so that the child control fills the parent control; the `center_2of3_global()` member function, which obtains the terminal's global size via `notcurses_term_dim_yx()`, calculates the y and x coordinates for centering its own plane, and calls `ncplane_move_yx()` to position the control at the two-thirds center position, and other advanced member functions; through the pre-encapsulated complex plane coordinate calculation functions, the planar layout of dynamic controls can be adjusted by directly calling the corresponding functions, eliminating the need for manual calculation of row and column coordinates.

[0018] The event handling layer is used to capture terminal input events asynchronously and distribute them to the corresponding dynamic controls in the graphical user interface. The event handling layer adopts a three-stage processing architecture of asynchronous listening, signal encapsulation, and slot distribution, which effectively overcomes UI lag caused by blocking input. This includes an asynchronous input monitoring thread independent of the main UI thread, which captures terminal input events in a non-blocking manner, generates Qt signals, sends them to the main UI thread, and then distributes them via the signal-slot mechanism.

[0019] Specifically, the event handling layer also includes: The asynchronous input listener module is used to capture terminal input events by repeatedly executing non-blocking terminal input acquisition functions through an asynchronous input listener thread. An asynchronous input listener thread, independent of the main UI thread, is created and started using the `QtConcurrent::run()` function. This thread executes in parallel with the main program's event loop, and internally calls the `notcurses_get_nblock()` function repeatedly to capture keyboard and mouse input events from the terminal in a non-blocking manner.

[0020] The event classification module is used to distinguish between keyboard events and mouse events when captured terminal input events are received. When an input event is captured, the asynchronous input monitoring thread encapsulates the raw input data into Qt signals and distinguishes between keyboard input events (such as letters, numbers, arrow keys, function keys) and mouse input events (such as clicks, movements, scroll wheels) based on the input type. The corresponding key_triggered(ncinput) or mouse_triggered(ncinput) signals can be sent accordingly.

[0021] The signal dispatch module, based on the identified keyboard or mouse events, uses Qt's signal and slot mechanism to send trigger signals to the corresponding dynamic controls. After event classification, the encapsulated event data is sent to the main UI thread as a signal via Qt's inter-thread signal and slot mechanism. The main UI thread receives this signal through Qt's signal and slot mechanism and connects to the event dispatch logic of the CApplication instance. The signal and slot then distribute the encapsulated event data to the currently focused target dynamic control, or pass it along the parent-child hierarchy, forming a rendering signal for the corresponding trigger event, thereby triggering a rendering request and changing the display state of the dynamic control.

[0022] The platform adaptation layer encapsulates the differences in terminal characteristics across different operating system platforms and provides the application management layer with operational interfaces for obtaining the size of the terminal's graphical interface, managing colors, and processing system signals. To ensure consistent application behavior across different operating systems, platforms, and terminal emulators, the API differences in terminal control across operating systems such as Linux, Windows, and macOS are shielded through the Terminal utility class and the encapsulated interface of CApplication.

[0023] Specifically, the platform adaptation layer also includes: The terminal size acquisition module is used to obtain the size information of the current display area from different terminals. It provides a unified notcurses_term_dim_yx() function interface, which internally encapsulates the size acquisition implementation for different platforms. It obtains the row and column numbers through a unified interface to obtain the size information of the current display area of ​​the terminal's graphical interface, while shielding the characteristics differences of the underlying platforms.

[0024] The color management module converts RGB color values ​​and transparency information into a color representation compatible with the current terminal. It defines a `ColorUnit` structure to encapsulate RGB color information and a `GradientUnit` structure to encapsulate transparency information. Then, it uses the `notcurses` channel or palette mechanism to adapt the encapsulated structures, ensuring that the optimal color representation strategy is automatically selected under different color support capabilities of different terminals. This maps RGB values ​​to terminal-recognizable color codes, achieving the closest possible display effect for the same color.

[0025] The system signal processing module is used to capture signals indicating changes in the current display area size or program interruption signals, and to modify the second atomic variable accordingly. By uniformly capturing and processing operating system signals, it captures system signals such as window size changes, suspension, and interruptions. For the SIGWINCH signal indicating a change in terminal window size, it automatically calls CApplication::refresh() to set the second atomic variable, triggering a full interface refresh and redraw. For the SIGTSTP signal indicating program suspension, it saves the current terminal state (including the ncplane hierarchy and cursor position), pauses rendering scheduling, and restores the state upon the SIGCONT signal (the resumption signal), ensuring consistent behavior across different operating systems.

[0026] Optionally, to ensure the correct display of complex text in the terminal's graphical interface, the system also includes a text processing layer, encapsulated in the Terminal utility class, providing static member functions for the control system layer to call. This layer performs width calculations and automatic layout processing on Unicode text in the terminal's graphical interface, resolving the issue of accurate display of multilingual text in the terminal environment. Specifically, this includes: The width calculation module is used to calculate the display width of Unicode text strings in the terminal's graphical interface. It iterates through the text string by calling the `ncstrwidth()` function from the `notcurses` library to distinguish the attributes of Unicode text strings containing multiple languages. For example, it returns a width of 1 for half-width characters and a width of 2 for full-width characters. For combined characters, it calculates the combined display width according to the Unicode standard. This allows for width statistics for characters such as Chinese, Japanese, and Korean, serving as the basis for text layout and alignment, and avoiding text formatting errors caused by calculating only the number of characters.

[0027] The text ellipsis module automatically truncates and adds an ellipsis when the display width of a Unicode text string exceeds a preset target width. It calculates the total text width by calling `text_length()` and compares it to the preset target width. If the calculated text display width exceeds the target width or the available width of the dynamic control it belongs to, it iterates and accumulates the width value of each character starting from the first character of the string until the remaining space can accommodate the ellipsis, then returns the concatenated result of the truncated string and the ellipsis. If it does not exceed the target width, it directly returns the original text.

[0028] The automatic line wrapping module is used to convert Unicode text strings exceeding a preset target width into multi-line text matrices. Using the `text_matrix()` function, long text strings exceeding the target width are split into multi-line text matrices according to the preset target width. Each line of text is validated using `text_length()` to ensure it does not exceed the target value. It supports breaking text by word boundaries or character boundaries, enabling automatic text formatting within the terminal's graphical interface and dynamic controls.

[0029] This embodiment constructs a layered architecture including an application management layer, a rendering scheduling layer, a control system layer, an event handling layer, and a platform adaptation layer. The rendering scheduling layer achieves the aggregation and delayed batch execution of rendering requests through atomic variable marking and timer checks. The control system layer provides an object-oriented interface construction method through dynamic controls inherited from the same base class and a parent-child relationship management mechanism. The event handling layer implements asynchronous input listening and distribution through independent threads and a signal-slot mechanism. The platform adaptation layer encapsulates the differences in terminal characteristics of different operating systems through a unified interface and also integrates a text processing layer that performs intelligent width calculation, omission, and line break processing for Unicode text. Thus, a complete graphical interface display system based on an event-driven architecture is constructed in the terminal environment. By using atomic variable marking and a timed batch rendering mechanism in the rendering scheduling layer, millisecond-level scattered rendering requests are aggregated into a unified output at a fixed frequency, significantly reducing the ANSI escape sequence parsing burden on the terminal emulator. The CView base class encapsulates the ncplane rendering plane and integrates a bidirectional mapping between the Qt object tree and the notcurses plane hierarchy, realizing automatic synchronization management of control lifecycle and rendering resources. Through precise width calculation and intelligent layout of Unicode monospace characters in the text processing layer, consistent text display in multilingual environments such as Chinese, Japanese, and Korean is ensured. By combining asynchronous input monitoring threads with the signal-slot mechanism, real-time response to user input is achieved without blocking interface rendering. Through unified encapsulation of the characteristics of different operating system terminals, consistent behavior of the application on different platforms is ensured.

[0030] Example 2 Figure 2 The flowchart of a terminal graphical interface display method based on an event-driven architecture according to Embodiment 2 of the present invention specifically includes the following steps: S101 executes system initialization, creates an application management object instance, initializes the core engine and standard rendering plane, and configures the rendering timer and asynchronous input listening thread.

[0031] First, the system is initialized by creating an instance of the CApplication object for application management. This instance first calls notcurses_init() to initialize the underlying rendering engine, creating a notcurses core instance and a standard rendering plane. Then, it configures and starts a QTimer instance for rendering, and uses QtConcurrent::run to start an asynchronous input monitoring thread.

[0032] S102, In the terminal graphical interface, multiple dynamic controls based on the same base class are instantiated, and the parent-child hierarchical relationship between each dynamic control is established through the constructor to form a control relationship description tree, so as to construct the terminal graphical interface.

[0033] After initialization, multiple dynamic controls can be instantiated in the terminal's graphical interface based on the same base class. For example, a `CView` object can be created as the main window, then used as the parent control, with its `ncplane` created as a child plane of the standard rendering plane, creating child controls such as `CTextView` and `CLineInput`. The parent control pointer is passed through the constructor to establish a control relationship description tree in the Qt object tree. The root node is the root plane managed by `CApplication`. The parent-child relationship of the `ncplane` allows traversing the rendering plane hierarchy, describing the logical hierarchy between controls, and determining the rendering order and event dispatch path. Afterwards, dynamic control properties can be set by calling functions such as `resize()`, `move()`, and `set_border()`, and `show()` can be called to make the dynamic controls visible. By using object-oriented declarative definition, a complete graphical user interface is formed.

[0034] S103, responding to user operation and modifying the rendering request flag, when the rendering request flag of any dynamic control changes, the corresponding atomic variable is set to true, but terminal rendering is not performed immediately.

[0035] When a user interacts with the control, the `CApplication::render()` or `CApplication::refresh()` function is called, setting the first atomic variable `atomic_bool_render` or the second atomic variable `atomic_bool_refresh` of the corresponding dynamic control to true, indicating a change in the control's state. At this time, the rendering function is not called to perform terminal rendering. For changes in control state such as text changes or position movement, the first atomic variable is modified to generate an update rendering request; for changes in size, the second atomic variable is modified to generate a refresh rendering request.

[0036] S104: Use the rendering timer to check each rendering request flag in each checking cycle. If any rendering request flag is true, perform a batch rendering screen redraw operation, draw all the content of the current graphical interface according to the control relationship description tree, and reset the rendering request flag to false.

[0037] Specifically, the rendering timer periodically checks the first and second atomic variables, and triggers a batch rendering and redrawing operation when either atomic variable is true.

[0038] The rendering timer QTimer triggers a timeout signal every 50ms, calling the CApplication::update() slot function to check the status of the first and second atomic variables. If either atomic variable is true, the batch rendering process is initiated: first, the size of the current terminal display area is obtained and verified to meet the minimum size set by the application; then, a unified rendering screen redraw is performed and displayed on the terminal. If there is no user interaction, the atomic variable is false.

[0039] An optional implementation of this embodiment is as follows: the batch rendering and redrawing operation includes obtaining the size of the current display area of ​​the terminal and verifying whether it meets the minimum size requirement. If the requirement is met, the standard rendering plane is cleared, the dynamic control border is drawn, and the text processing module is called to perform automatic line wrapping or omission processing. Finally, the graphical interface is output to the terminal through the underlying rendering engine.

[0040] When performing batch rendering and screen redrawing operations, the system first obtains the current display area size of the terminal, returns the current number of rows and columns, and verifies whether it meets the minimum size requirement. If the size is smaller than the minimum size set by CApplication, a warning message "Terminal size is too small, please adjust the window" is displayed in the center of the interface, and subsequent rendering is skipped. If the requirement is met, all content in the standard rendering plane is cleared. Then, starting from the root control, the control relationship description tree is traversed, and the paintEvent() method of each visible control is recursively called. Each called control draws its own visual representation (such as borders, text, background, etc.) onto its associated ncplane. When the text control is drawn, the text processing layer is called to calculate the text width, omission, or line break. After all controls are drawn, notcurses_render() is called. The notcurses engine is used to synthesize all ncplanes into a final frame, generate an ANSI escape sequence stream, merge the incremental updates of all planes through standard output, output them to the terminal, and reset the values ​​of two atomic variables to false.

[0041] S105 uses an asynchronous input listening thread to capture terminal input events in a non-blocking loop, distinguishes between keyboard input events and mouse input events, encapsulates them into input events, and sends a Qt signal to the main UI thread. Then, it uses signal slots to dispatch to the slot function of the corresponding target dynamic control in the control relationship description tree, triggering the state change of the dynamic control and modifying the value of the rendering request flag.

[0042] The asynchronous input listening thread runs continuously in the background after startup. It polls input events non-blockingly using notcurses_get_nblock(). When it captures keyboard or mouse input events, the thread categorizes them and encapsulates them into Qt signals. Then, it sends the event objects to the main UI thread's event queue by emitting Qt cross-thread signals. The main UI thread then uses the signal-slot mechanism in its event loop to dispatch the input event to the target dynamic control that is currently focused or at the mouse position in the control relationship description tree.

[0043] Specifically, the target dynamic control handles received input events by overriding predefined virtual functions for keyboard or mouse event responses in the base class. After receiving a dispatched input event, the target dynamic control processes the event in its slot function or the overridden virtual event handler `on_key_triggered()` to update its own state, such as appending characters to the input box, and modifies the corresponding dynamic control's atomic variables. This ensures real-time response to user input and prevents it from being blocked by batch rendering cycles.

[0044] S106, during system initialization, obtaining the current display area size of different terminals, or processing system signals, calls the encapsulated interface provided by the terminal-specific differences of different operating system platforms to obtain the current display area size of the terminal, perform color management, and process system signals. Since the terminal-specific differences of different operating system platforms have been pre-encapsulated, during system initialization, rendering operations, obtaining the display area size, or processing system signals, the unified interface provided by the encapsulation can be directly called to obtain the corresponding change information of the terminal, convert the RGB colors set by the application to the color mode supported by the current terminal, or when the operating system sends signals such as SIGWINCH, the system signal processing module captures and intercepts the signal, converts it into a call to refresh() in the main UI thread to set the flag bit (second atomic variable) of the refresh rendering request, and then recalculates the layout of all controls in the next rendering cycle to avoid display inconsistencies caused by the characteristic differences between different systems and platforms, thus achieving a consistent visual display effect across platforms.

[0045] In one optional implementation of this embodiment, the method further includes: During interface construction or state changes, for dynamic controls involving text display, the text processing module is called to calculate the display width of the Unicode text string and automatically wraps or omits text based on the size of the dynamic control. In the `paint()` function of `CTextView`, for each line of text to be displayed, `Terminal::text_length()` is called to calculate the total width, and `Terminal::text_elided()` (for single-line labels) or `Terminal::text_matrix()` (for multi-line text boxes) may be further called to perform layout calculations for automatic wrapping or omits. If the available width of the child text control changes due to a change in the size of the parent control, even if the text content remains unchanged, the text processing function must be called again with the new size parameters to re-layout the same text content, such as recalculating the wrapping or omits.

[0046] Optionally, automatic line wrapping or ellipsis processing includes, when the display width of the Unicode text string exceeds the available width of the dynamic control, adding the width character by character from the beginning of the string until the available width is reached, and replacing the remaining string with an ellipsis, or splitting the Unicode text string that exceeds the available width of the dynamic control according to the available width of the dynamic control to generate a multi-line text matrix.

[0047] When the display width of the text string in a dynamic control's `text()` subcontrol exceeds the control's available width, the `Terminal::text_elided()` function is called to perform ellipsis. It iterates from the first character of the string, accumulating the display width of all characters. Iteration stops when the accumulated width plus the width of the ellipsis (usually 3 characters) is about to exceed the target width. The accumulated valid characters are concatenated with the ellipsis to form the final display string. For text areas that support multi-line display, when text needs to wrap, the `Terminal::text_matrix()` function is called. This function splits the original text string according to the control's available width (target width), looping until the entire text string is processed, forming a two-dimensional string array, i.e., a multi-line text matrix.

[0048] This embodiment creates an application management object instance, initializes the core engine and standard rendering plane during system initialization, and configures a rendering timer and an asynchronous input listening thread. In the terminal graphical interface, multiple dynamic controls based on the CView base class are instantiated and a parent-child hierarchy is established to form a control relationship description tree to construct the user interface. In response to user operations, the rendering request is marked with the corresponding atomic variable set to true without immediately executing terminal rendering. The rendering timer periodically checks the request mark and performs a unified batch screen redraw operation. The asynchronous input listening thread captures terminal input events in a non-blocking loop, distinguishes the types, encapsulates them into Qt signals, sends them to the main UI thread, and distributes them to the target dynamic control through the signal slot to trigger state changes. By separating rendering request marking from batch rendering, control state changes are decoupled from screen output, preventing high-frequency state updates from directly causing high-frequency screen refreshes and significantly reducing CPU utilization and terminal I / O load. The control relationship description tree simultaneously maintains the Qt object tree logic hierarchy and the ncplane rendering plane hierarchy, achieving synchronous mapping between interface construction and underlying rendering. Through non-blocking capture of asynchronous input listening threads and main thread distribution of signals and slots, input waiting avoids blocking the main rendering loop, fundamentally changing the terminal graphics output mode. While ensuring interface responsiveness, it minimizes terminal parsing and refresh overhead, achieving low-latency interactive feedback and guaranteeing smooth interface visual display and data updates.

[0049] 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 terminal graphical user interface display system based on an event-driven architecture, characterized in that, include: The application management layer is used to initialize the terminal's graphical user interface environment and establish the connection between the Qt event loop and the underlying rendering engine. It manages the lifecycle of applications on the terminal and provides an object-oriented programming interface. The rendering scheduling layer is used to receive rendering requests from dynamic controls in the graphical interface and respond to the requests by performing aggregated and batch delayed graphical interface rendering. The control system layer is used to derive dynamic controls from multiple terminal graphical interfaces and construct the graphical interface. In response to interactive events generated by user operations on the graphical interface, it sends corresponding rendering requests to the rendering scheduling layer. The event handling layer is used to capture terminal input events through asynchronous listening and dispatch the input events to the corresponding dynamic controls in the graphical interface; The platform adaptation layer is used to encapsulate the differences in terminal characteristics across different operating system platforms and provide the application management layer with operation interfaces for obtaining the size of the terminal's graphical interface, managing colors, and processing system signals.

2. The system according to claim 1, characterized in that, The system also includes: The text processing layer is used to perform width calculations and automatic layout processing for Unicode text in the terminal's graphical interface, including: The width calculation module is used to calculate the display width of a Unicode text string in the terminal graphical interface; The text ellipsis module is used to automatically truncate and add an ellipsis when the display width of a Unicode text string exceeds the preset target width; The automatic line wrapping module is used to convert Unicode text strings that exceed the target width into multi-line text matrices based on a preset target width.

3. The system according to claim 1, characterized in that: The application management layer includes the CApplication class, which encapsulates a notcurses core instance and a standard rendering plane; The rendering scheduling layer includes a first atomic variable, a second atomic variable, and a rendering timer. The first atomic variable is used to mark the update rendering request status triggered by the update of the dynamic control. The second atomic variable is used to mark the refresh rendering request status triggered by the size change of the terminal graphical interface. The rendering timer triggers detection at a fixed period. The control system layer includes the CView base class, which inherits from QObject, and encapsulates an ncplane rendering plane instance to control the hierarchical relationship between parent and child dynamic controls. Event communication across dynamic controls is achieved through the signal slots of Qt meta-objects. The event handling layer includes an asynchronous input monitoring thread independent of the main UI thread. It captures terminal input events in a non-blocking manner, forms Qt signals, and sends them to the main UI thread, where they are then distributed by the signal-slot mechanism.

4. The system according to claim 3, characterized in that, The rendering scheduling layer also includes: The request marking module is used to mark the update rendering request and the refresh rendering request for size change of dynamic control by using the first atomic variable and the second atomic variable, respectively. The timed check module is used to check the status of the first atomic variable and the second atomic variable at a preset period by using a rendering timer; The batch rendering module is used to trigger a unified batch rendering screen redraw operation of the terminal graphical interface when the timed check module detects a rendering request to be processed, and to reset the first atomic variable and the second atomic variable after the redraw is completed.

5. The system according to claim 3, characterized in that, The control system layer also includes: The parent-child relationship management module is used to automatically establish and maintain the parent-child hierarchy and layout dependency relationships between dynamic controls based on the parent control parameters passed in when the CView base class is instantiated. The layout calculation module is used to adapt the size of the child dynamic control to the size of the parent dynamic control through member functions, or to center the child dynamic control in the terminal graphical interface through member functions.

6. The system according to claim 3, characterized in that, The event handling layer also includes: The asynchronous input listening module is used to capture terminal input events by repeatedly executing non-blocking terminal input acquisition functions through an asynchronous input listening thread. The event classification module is used to distinguish between keyboard events and mouse events when capturing terminal input events; The signal distribution module is used to send trigger signals to the corresponding dynamic controls based on the identified keyboard or mouse events, using Qt's signal slot mechanism.

7. The system according to claim 3, characterized in that, The platform adaptation layer also includes: The terminal size acquisition module is used to obtain the size information of the current display area from different terminals; The color management module is used to convert RGB color values ​​and transparency information into a color representation compatible with the current terminal. The system signal processing module is used to capture signals indicating changes in the size of the current display area or program interruptions, and to generate modification operations on the second atomic variable.

8. A terminal graphical interface display method for a terminal graphical interface display system based on an event-driven architecture as described in any one of claims 1-7, characterized in that, include: S101, execute system initialization, create application management object instance, initialize core engine and standard rendering plane, and configure rendering timer and asynchronous input listening thread; S102, Instantiate multiple dynamic controls based on the same base class in the terminal graphical interface, and establish the parent-child hierarchical relationship between each dynamic control through the constructor to form a control relationship description tree, so as to construct the terminal graphical interface; S103, responding to user operation and modifying the rendering request flag, when the rendering request flag of any dynamic control changes, the corresponding atomic variable is set to true, but terminal rendering is not performed immediately; S104: Use the rendering timer to check each rendering request flag in each checking cycle. If any rendering request flag is true, perform a batch rendering screen redraw operation, draw all the content of the current graphical interface according to the control relationship description tree, and reset the rendering request flag to false. S105 uses an asynchronous input listening thread to capture terminal input events in a non-blocking loop, distinguishes between keyboard input events and mouse input events, encapsulates them into input events, sends a Qt signal to the main UI thread, and then uses a signal slot to dispatch to the slot function of the corresponding target dynamic control in the control relationship description tree, triggering the state change of the dynamic control and modifying the value of the rendering request flag. S106, during system initialization, obtaining the current display area size of different terminals, or processing system signals, calls the encapsulated interface provided by the terminal-specific differences of different operating system platforms to obtain the current display area size of the terminal, perform color management, and process system signals.

9. The method according to claim 8, characterized in that, The method further includes: During interface construction or state change, for dynamic controls involving text display, the text processing module is called to calculate the display width of the Unicode text string, and automatic line wrapping or omission is performed according to the size of the dynamic control; S104 further includes periodically checking the first atomic variable and the second atomic variable using a rendering timer, and triggering a batch rendering screen redraw operation when either atomic variable is true. S105 further includes that the target dynamic control handles the received input events by overriding the predefined virtual function for keyboard or mouse event response in the base class.

10. The method according to claim 9, characterized in that: The automatic line wrapping or ellipsis processing includes, when the display width of the Unicode text string exceeds the available width of the dynamic control, accumulating the width character by character from the beginning of the string until the available width is reached, and replacing the remaining string with an ellipsis, or splitting the Unicode text string that exceeds the available width of the dynamic control according to the available width of the dynamic control to generate a multi-line text matrix; The batch rendering and redrawing operation includes obtaining the size of the current display area of ​​the terminal and verifying whether it meets the minimum size requirement. If the requirement is met, the standard rendering plane is cleared, dynamic control borders are drawn, and the text processing module is called to perform automatic line wrapping or omission processing. Finally, the graphical interface is output to the terminal through the underlying rendering engine.

Images