A window superposition-based touch input continuity guarantee method and system

Abstract

The application relates to the computer technical field, and in particular to a touch input continuity guarantee method and system based on window superposition. The method creates a target window and establishes a corresponding input event processing mechanism, determines a system input takeover area, generates a transparent superposition window on the area to form a superposition structure with the target window, thereby carrying an input takeover behavior, and enabling the target window to continuously receive touch input events. Subsequently, based on the input event processing mechanism, a continuous input event sequence is constructed according to the occurrence time sequence of the received touch input events, and touch interaction processing is performed according to the sequence, the continuity and stability of touch operation are realized, and the user interaction experience is improved. The application realizes decoupling of the system input takeover behavior and the touch event receiving process, guarantees that the target window continuously receives complete and continuous touch input events, and thereby improves the continuity, stability and user experience of touch interaction.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method and system for ensuring the continuity of touch input based on window overlay. Background Technology

[0002] In related technologies, with the rapid development of domestic operating systems and touch interaction devices, desktop systems and embedded systems, represented by the Kylin OS, have been widely used in scenarios such as touch all-in-one machines, industrial control terminals, self-service equipment, and smart conference terminals. In these application environments, touchscreens have become the primary human-computer interaction method, allowing users to control windows and interact with business processes through touch, swipe, and drag operations. To ensure a good user experience, applications typically need to continuously receive complete sequences of touch input events and perform interactive functions such as window dragging, interface switching, and object movement based on these continuous touch events.

[0003] However, existing touch input handling methods suffer from significant input continuity defects at window edges. In graphical user interface systems, the top edge of a window typically has a system input control area managed by the system window manager for system-level operations such as window movement and scaling. When touch input enters this area, the system window manager prioritizes taking over the input event, causing the sequence of touch events received by the application to be abnormally interrupted. This is particularly problematic in application frameworks like Qt that rely on continuous event sequences for interactive processing. Touch events may experience issues such as event loss, abnormal event triggering, and premature termination of dragging states, leading to window dragging stutters, operational failures, and even abnormal interaction logic. Furthermore, even if a borderless window solution is used to remove the system title bar, the system input control area still objectively exists, failing to fundamentally solve the problem of touch events being controlled by the system.

[0004] In summary, the technical problems existing in the relevant technologies need to be improved. Summary of the Invention

[0005] The main objective of this application is to propose a method and system for ensuring the continuity of touch input based on window overlay, so as to decouple the system input takeover behavior from the touch event receiving process, ensure that the target window continuously receives complete and continuous touch input events, thereby improving the continuity, stability and user experience of touch interaction.

[0006] To achieve the above objectives, one aspect of this application proposes a method for ensuring the continuity of touch input based on window overlay, the method comprising the following steps: Create a target window and establish an input event handling mechanism corresponding to the target window; Determine the system input takeover area corresponding to the target window; A transparent overlay window is created based on the system input takeover area; A window overlay structure is constructed based on the transparent overlay window and the target window; The window overlay structure is used to carry the input takeover behavior corresponding to the system input takeover area, so that the target window can continuously receive touch input events; According to the input event processing mechanism, a continuous input event sequence is constructed based on the touch input events received by the target window; Touch interaction processing is performed based on the continuous input event sequence.

[0007] In some embodiments, creating a target window and establishing an input event handling mechanism corresponding to the target window includes: Create a target window; the target window is used for interface display and touch interaction processing. Register an input event listening interface based on the target window; The input event listening interface is used to capture press events, move events, release events, and touch update events; Input event processing rules are constructed based on the press event, move event, release event, and touch update event. An input event processing mechanism is constructed based on the aforementioned input event processing rules.

[0008] In some embodiments, determining the system input takeover area corresponding to the target window includes: Obtain the boundary parameters of the target window; The system input takeover area located at the upper edge of the target window is determined based on the boundary parameters; The system input takeover area is dynamically adjusted based on window status parameters and system environment parameters; The system input takeover area is updated in response to window state change events; Output the updated system input takeover area information.

[0009] In some embodiments, creating a transparent overlay window based on the system input takeover area includes: Create a transparent overlay window that covers the system input takeover area; The transparent overlay window is set as a borderless window, a transparent background window, and a non-focus window; Configure the window size and position of the transparent overlay window according to the system input takeover area; The transparent overlay window is configured on top of the target window and below the system window using a Z-order control strategy. In response to the state change event of the target window, the window size and position of the transparent overlay window are adjusted synchronously.

[0010] In some embodiments, configuring the transparent overlay window above the target window and below the system window using a Z-order control strategy includes: Obtain the Z-order hierarchy information corresponding to the target window; The target layer position corresponding to the transparent overlay window is determined based on the Z-order layer information; The transparent overlay window is configured above the target window and below the system window using a Z-order control strategy. Establish a Z-order binding relationship between the transparent overlay window and the target window; In response to the layer change event of the target window, the layer position of the transparent overlay window is updated using the Z-order control strategy.

[0011] In some embodiments, constructing a window overlay structure based on the transparent overlay window and the target window includes: Obtain the window attribute information of the transparent overlay window and the target window; The association between the transparent overlay window and the target window is established based on the window attribute information; The coverage area corresponding to the transparent overlay window is matched with the system input takeover area to generate a matching result; A window overlay structure is formed based on the aforementioned associations and matching results.

[0012] In some embodiments, utilizing the window overlay structure to carry the input takeover behavior corresponding to the system input takeover area, so that the target window continuously receives touch input events, includes: Acquire touch input events that act on the system input takeover area; Based on the window overlay structure, the window where the touch input event is hit is determined to be the transparent overlay window; The transparent overlay window is used to carry the input takeover behavior corresponding to the system input takeover area; The input takeover behavior is suppressed and applied to the target window; Maintain the touch input event receiving state of the target window.

[0013] In some embodiments, utilizing the transparent overlay window to carry the input takeover behavior corresponding to the system input takeover area includes: The system receives touch input events applied to the system input takeover area through the transparent overlay window. Generate a corresponding system-level window operation request based on the touch input event; The system-level window operation request is isolated to prevent it from acting on the target window. Maintain the coverage of the system input takeover area by the transparent overlay window; The input takeover behavior is limited to the transparent overlay window.

[0014] In some embodiments, constructing a continuous sequence of input events based on the touch input events received by the target window according to the input event processing mechanism includes: The touch input event corresponding to the target window is received based on the input event processing mechanism. The touch input events are associated and organized according to their occurrence sequence to generate an input event chain; Based on the input event chain, the time interval between adjacent touch input events is calculated according to the timestamp information corresponding to the touch input event; The time interval is compared with a preset time threshold to determine the continuity status of the touch input event; The touch input events are organized sequentially according to the event continuity state to generate a continuous input event sequence.

[0015] To achieve the above objectives, another aspect of this application proposes a touch input continuity assurance system based on window overlay, the system comprising: The target window creation module is used to create a target window and establish an input event handling mechanism corresponding to the target window; The region determination module is used to determine the system input takeover region corresponding to the target window; A transparent overlay window construction module is used to create a transparent overlay window based on the system input takeover area; An overlay structure construction module is used to construct a window overlay structure based on the transparent overlay window and the target window; The continuous protection module is used to carry the input takeover behavior corresponding to the system input takeover area using the window overlay structure, so that the target window continuously receives touch input events; A sequence construction module is used to construct a continuous sequence of input events based on the touch input events received by the target window according to the input event processing mechanism. The touch interaction processing module is used to perform touch interaction processing based on the continuous input event sequence.

[0016] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0017] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0018] To achieve the above objectives, another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0019] The embodiments of this application include at least the following beneficial effects: This application provides a method and system for ensuring the continuity of touch input based on window overlay. This solution creates a transparent overlay window in the system input takeover area corresponding to the target window and constructs a window overlay structure with the target window, thereby decoupling the system input takeover behavior from the target window's touch event reception. This effectively solves the problem of touch events being interrupted due to system takeover in the prior art. Utilizing this overlay structure to carry the input takeover behavior ensures that the target window always maintains an input event receiving state during the touch process, avoiding event interruptions caused by focus switching or area interception. Simultaneously, through an input event processing mechanism, the touch input events received by the target window are continuously collected, constructing a complete continuous input event sequence. This ensures the temporal integrity and logical consistency of touch actions, improving the accuracy of trajectory recognition and gesture processing. Performing touch interaction processing based on this continuous event sequence can improve the response effect of gesture recognition, trajectory drawing, continuous dragging, and other operations, enhancing the user interaction experience. This method is low-cost, highly compatible, requires no modification to the underlying system input framework, and is suitable for drawing applications, game interaction, and multi-touch scenarios, improving the continuity of touch input and the user interaction experience. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating a method for ensuring the continuity of touch input based on window overlay, provided in an embodiment of this application. Figure 2 yes Figure 1 A flowchart illustrating step S3 in the process; Figure 3 yes Figure 1 A flowchart illustrating step S5 in the process; Figure 4 This is a schematic diagram of a touch input continuity assurance system based on window overlay provided in an embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0022] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0023] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0024] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0025] Before providing a detailed description of the embodiments of this application, some of the nouns and terms used in the embodiments of this application will be explained first. The nouns and terms used in the embodiments of this application shall be interpreted as follows: The target window refers to the window object created by the application and used for interface display and touch interaction processing, serving as the main receiver of touch input events and the carrier for business logic execution; The input event handling mechanism refers to a set of rules for event listening, event parsing, event caching, state maintenance, and continuity detection established for touch input events, which are used to receive, process, and manage touch input events. The system input takeover area refers to the window area that is given priority to receiving or taking over input events by the operating system window manager. It is usually located at the edge of the window and is used to perform system-level operations such as window movement and scaling. A transparent overlay window is a transparent window that covers the system input takeover area. It has a transparent background, no border, and non-focus attributes. It is used to carry out system input takeover behavior without affecting the normal display of the target window. A window overlay structure refers to a composite window structure formed by a transparent overlay window and a target window according to a preset hierarchical relationship. It is used to decouple the system input takeover behavior from the touch input event receiving process. Touch input events refer to input events generated by touch screen devices and transmitted to the window system, including press events, move events, release events, and touch update events. The input event listening interface is a software interface used to listen for, capture, and receive touch input events, and to pass touch input events to the input event processing mechanism. The continuity state refers to the event state obtained by comparing the time interval between adjacent touch input events with a preset time threshold, which is used to characterize whether the touch input process remains continuous. Z-order control strategy refers to a window management strategy used to control the overlapping relationship of multiple windows in the display hierarchy. By adjusting the Z-order hierarchy of windows, a transparent overlay window can be positioned above the target window and below the system window to achieve the display effect. Z-order hierarchy refers to the hierarchical order of windows in a graphical interface display system, used to represent the overlapping relationship between windows; System-level window operation requests refer to operation requests triggered by touch input events and used to perform system management functions such as window movement, window scaling, or window state switching. Touch interaction processing refers to the interactive logic processing process executed based on a continuous sequence of input events, including gesture recognition, trajectory drawing, window dragging, object movement, multi-touch, and interface control. Qt (Qt Framework) is a cross-platform graphical user interface application development framework used to build graphical interfaces, event handling mechanisms, and human-computer interaction functions. X11 (X Window System) refers to the window system protocol widely used in Linux and Unix-like operating systems to implement graphical interface display and window management functions; Wayland (Wayland Protocol) refers to a new generation of Linux graphics display protocol and window system architecture, used to enable graphics display and input event communication between applications and display servers; DPI (Dots Per Inch) refers to the number of dots per inch, used to represent the pixel density of a display device. It is an important parameter for scaling and adapting graphical interfaces. QWidget (QWidget Class) refers to the basic window component class in the Qt framework. It is the base class for creating general window objects or interface controls, and supports interface display, event listening, drawing, and input event reception. It is the most basic visual element in building a graphical interface. QMainWindow (QMainWindow Class) is the main window class in the Qt framework. It is used to create a standard application main window with a menu bar, toolbar, status bar, and central window area. It inherits from QWidget and extends the main window layout and management functions. It is suitable for hosting the main interface and touch interaction of the application.

[0026] This application provides a method and system for ensuring the continuity of touch input based on window overlay. This solution creates a transparent overlay window in the system input takeover area corresponding to the target window and constructs a window overlay structure with the target window, decoupling the system input takeover behavior from the target window's touch event reception. This effectively solves the problem of touch event interruption due to system takeover in existing technologies. By using this overlay structure to carry the input takeover behavior, the target window maintains an input event receiving state throughout the touch process, avoiding event interruptions caused by focus switching or area interception. Simultaneously, through an input event processing mechanism, touch input events received by the target window are continuously collected, constructing a complete continuous input event sequence. This ensures the temporal integrity and logical consistency of touch actions, improving the accuracy of trajectory recognition and gesture processing. Performing touch interaction processing based on this continuous event sequence improves the response effect of gesture recognition, trajectory drawing, continuous dragging, and other operations, enhancing the user experience. This method is low-cost, highly compatible, requires no modification to the underlying system input framework, and is suitable for drawing applications, game interaction, and multi-touch scenarios, improving the continuity of touch input and the user experience.

[0027] This application provides a method for ensuring the continuity of touch input based on window overlay, relating to the field of computer technology. This method can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or in-vehicle terminal, but is not limited thereto. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing a method for ensuring the continuity of touch input based on window overlay, but is not limited to the above forms.

[0028] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0029] Figure 1 This is an optional flowchart of a touch input continuity guarantee method based on window overlay provided in an embodiment of this application. Figure 1 The method may include, but is not limited to, steps S1 to S7: S1: Create the target window and establish an input event handling mechanism corresponding to the target window; This includes creating a target window and establishing an input event handling mechanism corresponding to the target window, including: S11: Create a target window; this target window is used for interface display and touch interaction processing; S12: Register an input event listener interface based on the target window; S13: Capture press events, move events, release events, and touch update events using the input event listener interface; S14: Construct input event handling rules based on press events, move events, release events, and touch update events; S15: Construct an input event handling mechanism based on input event handling rules.

[0030] In this embodiment, a target window is first created using the window management interface provided by the operating system. The target window is used for interface display and touch interaction processing, serving as the main display and input event consumer for the application. Specifically, the QWidget or QMainWindow class in the Qt framework can be called to create a window object, and the initial window size, display mode, and window state can be set to ensure that the target window can fully support subsequent touch operations and interface control display.

[0031] Subsequently, an input event listener interface is registered based on the target window. Specifically, touch event and mouse event listeners are registered in the target window, including the following event types: Press Event, Move Event, Release Event, and Touch Update Event. Touch or mouse input is transmitted to the target window in real time through an event loop and event dispatch, ensuring that events arrive at the processing module completely in chronological order.

[0032] After registering the listening interface, various touch events are captured using the input event listening interface. Input event handling rules are then constructed based on the captured press, move, release, and touch update events. These rules include the event touch point number, timestamp, coordinate position, and window state information, describing the complete information and sequence of events. Events are categorized, filtered, and their states managed according to their type and attributes, thus forming a complete event handling logic.

[0033] Furthermore, an input event processing mechanism is constructed based on input event processing rules. This mechanism includes event caching, event parsing, event state maintenance, and continuity detection, ensuring that the target window can continuously process the user's touch operations in the order of events, achieving smooth dragging, swiping, and multi-touch operations. In this embodiment, the input event processing mechanism provides a fundamental guarantee for the subsequent window overlay structure and transparent window mechanism, ensuring that the target window can stably and continuously receive the complete sequence of input events throughout the entire touch interaction process.

[0034] S2: Determine the system input takeover area corresponding to the target window; Among these, determining the system input takeover area corresponding to the target window includes: S21: Obtain the boundary parameters of the target window; S22: Determine the system input takeover area located at the upper edge of the target window based on boundary parameters; S23: Dynamically adjust the system input takeover area based on window status parameters and system environment parameters; S24: Update the system input takeover area in response to window state change events; S25: Output the updated system input takeover area information.

[0035] In this embodiment, after the target window is created, its boundary parameters are obtained, and the system input takeover area corresponding to the upper edge of the target window is determined based on these parameters. Specifically, the boundary parameters include the upper left corner coordinates of the target window in the screen coordinate system, the window width, the window height, the window decoration boundary height, and the display scaling ratio. In the X11 environment, the window frame extension attribute _NET_FRAME_EXTENTS is read through the window attribute acquisition interface, and the top boundary parameter is extracted as the initial height of the system input takeover area; in the Wayland environment, the height of this area can be derived by combining the window state, display resolution, and DPI scaling ratio.

[0036] Specifically, the upper edge of the target window is defined as the system input takeover area. This system input takeover area represents the region where the system window manager preferentially receives or takes over input events. Assume the coordinates of the upper left corner of the target window are... Window width is The system input control area height is Then the region can be represented as .in The height can be set to 8 to 16 pixels depending on the actual system environment, or it can be dynamically calculated based on the window boundary parameters. When the target window is in a normal window state, the height of the system input takeover area can be a larger value; when the target window is maximized or borderless, the height of the system input takeover area can be reduced or recalibrated based on the actual hit test results.

[0037] Furthermore, the system input takeover area is dynamically adjusted based on window state parameters and system environment parameters. Window state parameters include the target window's maximized, restored, borderless, moved, and resized states; system environment parameters include DPI scaling ratio, current monitor resolution, multi-monitor layout information, and window manager type. When a window state change event occurs, such as a window size change, screen switching, DPI change, maximized, or restored event, the target window's boundary parameters are reacquired, and the system input takeover area is recalculated. After calculation, the updated system input takeover area information is output, including area coordinates, area width, area height, and area update time, providing accurate area information for subsequent creation of transparent overlay windows.

[0038] S3: Create a transparent overlay window based on the system input takeover area; Among them, reference Figure 2 As shown, a transparent overlay window is created based on the system input takeover area, including: S31: Create a transparent overlay window that covers the system input takeover area; S32: Set the transparent overlay window to a borderless window, a transparent background window, and a non-focus window; S33: Configure the window size and position of the transparent overlay window according to the system input takeover area; S34: Configure the transparent overlay window above the target window and below the system window using the Z-order control strategy; S35: Respond to the state change event of the target window and synchronously adjust the window size and position of the transparent overlay window.

[0039] Specifically, the transparent overlay window is configured above the target window and below the system window using a Z-order control strategy, including: S341: Obtain the Z-order level information corresponding to the target window; S342: Determine the target layer position corresponding to the transparent overlay window based on the Z-order layer information; S343: Use the Z-order control strategy to configure the transparent overlay window above the target window and below the system window; S344: Establish the Z-order binding relationship between the transparent overlay window and the target window; S345: Respond to the layer change event of the target window and update the layer position of the transparent overlay window using the Z-order control strategy.

[0040] In this embodiment, after determining the system input takeover area corresponding to the target window, a transparent overlay window is created based on the system input takeover area. This transparent overlay window is used to cover the system input takeover area at the upper edge of the target window, so that the input hit object in this area is transferred from the target window to the transparent overlay window, thereby preventing the system window manager from directly taking over the touch input events of the target window. Specifically, a transparent overlay window is created according to the system input takeover area information, and this transparent overlay window is set as a borderless window, a transparent background window, and a non-focus window. Among them, a borderless window means that the window does not display a title bar and border decoration; a transparent background window means that the window does not draw visible background content and does not affect the display of the target window interface; a non-focus window means that the window does not participate in input focus competition and does not change the activation state of the target window.

[0041] Specifically, the window size and position of the transparent overlay window are configured based on the system input control area. If the system input control area information includes the coordinates of the top-left corner of the area... Area width and regional height Then the coordinates of the top left corner of the transparent overlay window are set to Window width set to Window height set to To avoid incomplete coverage due to display scaling, boundary offset, or coordinate rounding errors, the height of the transparent overlay window can be adjusted. A preset redundancy value is added to the base layer, for example, by 2 to 4 pixels, so that the transparent overlay window can completely cover the system input takeover area. After creation, the transparent overlay window does not display any visual content; it exists solely as the window to carry out the system input takeover behavior.

[0042] Furthermore, a Z-order control strategy is used to configure the transparent overlay window above the target window and below the system window. Z-order refers to the window's position relative to the screen display hierarchy; the Z-order control strategy controls the layer position of the transparent overlay window relative to the target window and system windows. First, the Z-order layer information corresponding to the target window is obtained, such as the current layer of the target window's ordinary application window, its on-top status, and its active status. Then, based on this Z-order layer information, the target layer position of the transparent overlay window is determined, ensuring that the transparent overlay window is above the target window but below system windows such as the taskbar, system pop-ups, and desktop windows. Through this layer configuration, the transparent overlay window can cover the system input control area of ​​the target window without obscuring or interfering with the normal display and input response of system-level windows.

[0043] After configuring the hierarchy, a Z-order binding relationship is established between the transparent overlay window and the target window. This Z-order binding relationship ensures that the transparent overlay window adjusts synchronously with changes in the target window's hierarchy. For example, when the target window is activated, brought to the foreground, moved, maximized, restored, or switched from the background to the foreground, the transparent overlay window updates to the target hierarchy position above the target window. When the target window loses focus or is obscured by other application windows, the transparent overlay window also lowers its hierarchy accordingly, preventing it from floating independently above other windows. This method ensures that the transparent overlay window always maintains a corresponding relationship with the target window and will not display independently of the target window.

[0044] Furthermore, in response to state change events of the target window, the window size, window position, and layer position of the transparent overlay window are adjusted synchronously. These state change events include window movement events, window size change events, window maximization events, window restore events, screen switching events, DPI change events, and layer change events. When responding to these events, the system re-acquires the boundary parameters of the target window and the system input takeover area information, and resets the coordinates, width, height, and Z-order layer of the transparent overlay window based on the updated area information. When the target window is closed or destroyed, the transparent overlay window is destroyed synchronously; when the target window is hidden or minimized, the transparent overlay window is hidden synchronously. Thus, the transparent overlay window can continuously and accurately cover the system input takeover area throughout the entire operation of the target window, providing a stable foundation for subsequent window overlay structure construction and handling of input takeover behavior.

[0045] S4: Construct a window overlay structure based on a transparent overlay window and a target window; The method of constructing a window overlay structure based on a transparent overlay window and a target window includes: S41: Obtain window attribute information for the transparent overlay window and the target window; S42: Establish the association between the transparent overlay window and the target window based on window attribute information; S43: Match the coverage area corresponding to the transparent overlay window with the system input takeover area to generate a matching result; S44: Form a window overlay structure based on the association relationship and matching results.

[0046] In this embodiment, after the transparent overlay window is created, the window attribute information of the transparent overlay window and the target window is obtained. This window attribute information includes window coordinates, window size, display state, hierarchy information, and visible area information. Subsequently, based on the window attribute information, a relationship is established between the transparent overlay window and the target window, enabling them to achieve positional, size, and display state linkage. When the target window undergoes state changes such as moving, scaling, maximizing, minimizing, or hiding, the transparent overlay window can synchronously perform corresponding adjustment operations, thereby ensuring that the two always maintain a corresponding relationship.

[0047] Specifically, the coverage area corresponding to the transparent overlay window is matched with the system input control area. During the matching process, the coordinate range, width parameters, and height parameters of both the coverage area and the system input control area are obtained, and region overlap detection and boundary alignment calculations are performed to determine whether the transparent overlay window completely covers the system input control area. When an offset, insufficient coverage, or boundary exceeding a preset range is detected in the coverage area, the system automatically adjusts the position and size parameters of the transparent overlay window until the transparent overlay window and the system input control area meet the preset matching conditions, thereby generating the corresponding matching result.

[0048] Furthermore, a window overlay structure is formed based on the association relationships and matching results. This window overlay structure includes a target window at the bottom layer and a transparent overlay window located at the top edge of the target window. The target window is used to perform interface display and touch input processing, while the transparent overlay window is used to cover the system input takeover area and carry the corresponding input hit behavior. By constructing the window overlay structure, the system input takeover area and the input processing area of ​​the target window are separated from each other at the structural level, thus providing the foundation for subsequently using the transparent overlay window to carry out system input takeover behavior.

[0049] S5: Utilize the window overlay structure to carry the input takeover behavior corresponding to the system input takeover area, so that the target window can continuously receive touch input events; Among them, reference Figure 3 As shown, the input takeover behavior corresponding to the input takeover area of ​​the system is carried by a window overlay structure, so that the target window continuously receives touch input events, including: S51: Acquire touch input events that act on the system input takeover area; S52: Based on the window overlay structure, the window where the touch input event is hit is determined as a transparent overlay window; S53: Use a transparent overlay window to carry the input takeover behavior corresponding to the system input takeover area; S54: Suppress input takeover behavior on the target window; S55: Maintain the touch input event receiving state of the target window.

[0050] In this embodiment, when a user performs a window dragging operation on the touchscreen, the system acquires touch input events acting on the system's input control area in real time. These touch input events include press events, move events, release events, and touch update events, and also carry information such as touch point number, timestamp, and touch coordinates. The system continuously monitors the input status through an input event listening interface and sends the acquired touch input events to the window management module for processing.

[0051] Subsequently, event hit detection is performed based on the window overlay structure. When a touch coordinate is detected within the system input takeover area, since the transparent overlay window covers this area, the hit window of the current touch input event is preferentially identified as the transparent overlay window, rather than the target window. At this time, the input target object recognized by the system window manager changes from the target window to the transparent overlay window, thereby transferring the system input takeover behavior that might have originally acted on the target window to the transparent overlay window.

[0052] After identifying the transparent overlay window as the target window, it is used to carry the input takeover behavior corresponding to the system input takeover area. Specifically, when the system window manager attempts to trigger system-level operations such as window movement, dragging, or scaling based on the current touch input event, the relevant input takeover behavior is first applied to the transparent overlay window. Since the transparent overlay window is configured as a borderless window, a transparent background window, and a non-focus window, and does not execute window movement logic, window scaling logic, or business processing logic, the transparent overlay window only exists as a carrier for input takeover behavior and does not trigger the corresponding system operation.

[0053] Furthermore, an event avoidance mechanism is implemented based on the transparent overlay window. Specifically, when a touch input event enters the system input takeover area, the transparent overlay window receives the touch input event but does not perform any business processing on it, nor does it trigger the corresponding default behavior of the system window manager. This restricts the system input takeover behavior to within the transparent overlay window. Through the event avoidance mechanism, the system window manager will not perform window movement, window scaling, or input takeover operations on the target window, thereby isolating the system input takeover behavior.

[0054] Because the system's input takeover behavior is carried out by a transparent overlay window and isolated through an event avoidance mechanism, the input takeover behavior will not affect the target window. At this time, the target window remains in a state of receiving touch input events, continuously receiving complete press events, move events, release events, and touch update events, thus forming a continuous sequence of input events. Even if the user's touch trajectory enters the upper edge area of ​​the target window, no abnormal release events, touch interruptions, or drag failures will occur, ultimately ensuring the continuity of touch input.

[0055] Specifically, the input takeover behavior corresponding to the system input takeover area is carried using a transparent overlay window, including: S531: Receives touch input events applied to the system input takeover area through a transparent overlay window; S532: Generate corresponding system-level window operation requests based on touch input events; S533: Isolate system-level window operation requests to prevent them from acting on the target window; S534: Maintain the coverage of the system input takeover area by the transparent overlay window; S535: Limit input takeover behavior to transparent overlay windows.

[0056] In this embodiment, the transparent overlay window receives touch input events from the system input takeover area. These touch input events are captured through an input event listening interface and written to the input event buffer of the transparent overlay window, providing complete data for subsequent processing.

[0057] Subsequently, corresponding system-level window operation requests are generated based on the captured touch input events. These system-level window operation requests include window dragging requests, window scaling requests, and window focus change requests, used to simulate default operation behaviors triggered in the system input takeover area. Under normal circumstances, these requests are directly applied to the target window by the system window manager, which may result in interrupted dragging or loss of input events.

[0058] To prevent system operations from affecting the target window, system-level window operation requests are isolated. Specifically, the transparent overlay window processes system-level operation requests within its own window without passing them to the target window. This isolation confines system-level window operation requests within the transparent overlay window, maintaining the system window manager's input control behavior while avoiding actual interference with the target window. Throughout this process, the transparent overlay window maintains its coverage of the system input control area, ensuring that this area is always contained within the transparent overlay window.

[0059] Furthermore, event avoidance is achieved by limiting input takeover behavior to a transparent overlay window. Specifically, all touch input events acting on the system's input takeover area are received and isolated by the transparent overlay window, while the target window continuously maintains its touch input event receiving state. In this way, the target window can fully receive press, move, release, and touch update events, ensuring the integrity of the continuous input event sequence and guaranteeing touch input continuity.

[0060] S6: Based on the input event processing mechanism, construct a continuous input event sequence based on the touch input events received by the target window; Specifically, based on the input event processing mechanism, a continuous sequence of input events is constructed based on the touch input events received by the target window, including: S61: Receive touch input events corresponding to the target window based on the input event handling mechanism; S62: Organize touch input events according to their occurrence sequence to generate an input event chain; S63: Based on the input event chain, calculate the time interval between adjacent touch input events according to the timestamp information corresponding to the touch input event; S64: Compare the time interval with a preset time threshold to determine the continuity status of the touch input event; S65: Organize touch input events sequentially according to the event continuity state to generate a continuous input event sequence.

[0061] In this embodiment, while the target window maintains a touch input event receiving state, it receives touch input events corresponding to the target window based on the input event processing mechanism. When the target window receives a touch input event, it first identifies the event according to the touch point number and event type, and groups events belonging to the same touch operation into the same event processing channel.

[0062] Specifically, touch input events received by the target window are associated and organized according to their occurrence sequence to generate an input event chain. This input event chain represents the sequential relationship between events in a complete touch operation. For example, a press event serves as the starting point of the chain, multiple movement events or touch update events serve as intermediate nodes, and a release event serves as the ending point. For single-point touch scenarios, an input event chain is established based on the same touch point number; for multi-point touch scenarios, independent input event chains are established for different touch point numbers to avoid confusion of movement trajectories between different touch points. In this way, the system can organize discrete input events into event chains with temporal relationships.

[0063] Furthermore, based on the input event chain, the time interval between adjacent touch input events is calculated according to the timestamp information corresponding to each touch input event. Specifically, let the timestamp of the current touch input event be... The timestamp of the previous touch input event is Then the time interval between adjacent events is The time interval With preset time threshold If a comparison is made, Less than or equal to If, then it is determined that adjacent touch input events are in a continuous state; if Greater than If a press event occurs but no valid movement event is received, movement events are abnormally missing, or release events occur prematurely, then the current event chain is determined to have a continuity anomaly.

[0064] After determining the continuity of touch input events, the events are organized sequentially according to this continuity to generate a continuous input event sequence. For event chains with normal continuity, press events, move events, touch update events, and release events are arranged in ascending order of timestamps to form a complete continuous input event sequence. For event chains with abnormalities, state compensation or abnormal nodes can be performed based on the most recent valid event, and the continuity of the event chain can be restored as the target window continues to receive subsequent valid events. In this way, the target window can obtain a complete and seamless sequence of press, move, and release input events, providing a reliable data foundation for subsequent window dragging, interface swiping, or multi-touch processing.

[0065] S7: Performs touch interaction processing based on a continuous sequence of input events.

[0066] In this embodiment, after obtaining the sequence of continuous input events, corresponding touch interaction processing is performed based on the sequence. Specifically, touch press events, touch move events, and touch release events in the continuous input event sequence are parsed, and the corresponding interaction type is determined according to the temporal relationship between each event. When a drag operation is detected, touch trajectory information is extracted, and the change in touch position is calculated to provide a data basis for subsequent window movement processing.

[0067] Specifically, when a touch press event is received, the initial touch coordinates and the current position of the target window are recorded. When a touch move event is received, the current touch coordinates are obtained, and the position offset between the current touch coordinates and the initial touch coordinates is calculated. Then, the position coordinates of the target window are updated based on the position offset, and the window movement interface is called to refresh the window position, thereby enabling the target window to move synchronously with the touch trajectory. Since the target window continuously receives a complete sequence of touch events throughout the dragging process, the window movement process remains continuous and smooth.

[0068] Furthermore, after completing the window movement process, a touch release event is received, and the current touch interaction process ends, while the corresponding drag state resources are released. In some implementations, touch interaction operations such as dragging interface elements, multi-touch gesture recognition, window scaling, and sliding control can also be performed based on a continuous sequence of input events. By performing touch interaction processing based on a continuous sequence of input events, the event interruption problem caused by system input takeover can be effectively avoided, improving the stability and continuity of the window dragging process and the user interaction experience.

[0069] Please see Figure 4 This application also provides a touch input continuity assurance system based on window overlay, the system comprising: The target window creation module is used to create a target window and establish an input event handling mechanism corresponding to the target window; The region determination module is used to determine the system input takeover region corresponding to the target window; The transparent overlay window building module is used to create transparent overlay windows based on the system input takeover area; The overlay structure building module is used to construct window overlay structures based on transparent overlay windows and target windows. The continuous protection module is used to carry the input takeover behavior corresponding to the system input takeover area by using the window overlay structure, so that the target window can continuously receive touch input events; The sequence construction module is used to construct a continuous sequence of input events based on the touch input events received by the target window, according to the input event processing mechanism. The touch interaction processing module is used to perform touch interaction processing based on a continuous sequence of input events.

[0070] It is understood that the content of the above method embodiments is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0071] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0072] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0073] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0074] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0075] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0076] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0077] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0078] This application provides a method and system for ensuring the continuity of touch input based on window overlay. This solution creates a transparent overlay window in the system input takeover area corresponding to the target window and constructs a window overlay structure with the target window, decoupling the system input takeover behavior from the target window's touch event reception. This effectively solves the problem of touch event interruption due to system takeover in existing technologies. By using this overlay structure to carry the input takeover behavior, the target window maintains an input event receiving state throughout the touch process, avoiding event interruptions caused by focus switching or area interception. Simultaneously, through an input event processing mechanism, touch input events received by the target window are continuously collected, constructing a complete continuous input event sequence. This ensures the temporal integrity and logical consistency of touch actions, improving the accuracy of trajectory recognition and gesture processing. Performing touch interaction processing based on this continuous event sequence improves the response effect of gesture recognition, trajectory drawing, continuous dragging, and other operations, enhancing the user experience. This method is low-cost, highly compatible, requires no modification to the underlying system input framework, and is suitable for drawing applications, game interaction, and multi-touch scenarios, improving the continuity of touch input and the user experience.

[0079] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0080] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0081] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0082] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0083] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for ensuring the continuity of touch input based on window overlay, characterized in that, The method includes the following steps: Create a target window and establish an input event handling mechanism corresponding to the target window; Determine the system input takeover area corresponding to the target window; A transparent overlay window is created based on the system input takeover area; A window overlay structure is constructed based on the transparent overlay window and the target window; The window overlay structure is used to carry the input takeover behavior corresponding to the system input takeover area, so that the target window can continuously receive touch input events; According to the input event processing mechanism, a continuous input event sequence is constructed based on the touch input events received by the target window; Touch interaction processing is performed based on the continuous input event sequence.

2. The method according to claim 1, characterized in that, The creation of the target window and the establishment of an input event handling mechanism corresponding to the target window include: Create a target window; the target window is used for interface display and touch interaction processing. Register an input event listening interface based on the target window; The input event listening interface is used to capture press events, move events, release events, and touch update events; Input event processing rules are constructed based on the press event, move event, release event, and touch update event. An input event processing mechanism is constructed based on the aforementioned input event processing rules.

3. The method according to claim 1, characterized in that, Determining the system input takeover area corresponding to the target window includes: Obtain the boundary parameters of the target window; The system input takeover area located at the upper edge of the target window is determined based on the boundary parameters; The system input takeover area is dynamically adjusted based on window status parameters and system environment parameters; The system input takeover area is updated in response to window state change events; Output the updated system input takeover area information.

4. The method according to claim 1, characterized in that, Creating a transparent overlay window based on the system input takeover area includes: Create a transparent overlay window that covers the system input takeover area; The transparent overlay window is set as a borderless window, a transparent background window, and a non-focus window; Configure the window size and position of the transparent overlay window according to the system input takeover area; The transparent overlay window is configured on top of the target window and below the system window using a Z-order control strategy. In response to the state change event of the target window, the window size and position of the transparent overlay window are adjusted synchronously.

5. The method according to claim 4, characterized in that, The step of configuring the transparent overlay window above the target window and below the system window using the Z-order control strategy includes: Obtain the Z-order hierarchy information corresponding to the target window; The target layer position corresponding to the transparent overlay window is determined based on the Z-order layer information; The transparent overlay window is configured above the target window and below the system window using a Z-order control strategy. Establish a Z-order binding relationship between the transparent overlay window and the target window; In response to the layer change event of the target window, the layer position of the transparent overlay window is updated using the Z-order control strategy.

6. The method according to claim 1, characterized in that, The construction of a window overlay structure based on the transparent overlay window and the target window includes: Obtain the window attribute information of the transparent overlay window and the target window; The association between the transparent overlay window and the target window is established based on the window attribute information; The coverage area corresponding to the transparent overlay window is matched with the system input takeover area to generate a matching result; A window overlay structure is formed based on the aforementioned associations and matching results.

7. The method according to claim 1, characterized in that, The method of utilizing the window overlay structure to carry the input takeover behavior corresponding to the system input takeover area, so that the target window continuously receives touch input events, includes: Acquire touch input events that act on the system input takeover area; Based on the window overlay structure, the window where the touch input event is hit is determined to be the transparent overlay window; The transparent overlay window is used to carry the input takeover behavior corresponding to the system input takeover area; The input takeover behavior is suppressed and applied to the target window; Maintain the touch input event receiving state of the target window.

8. The method according to claim 7, characterized in that, The method of using the transparent overlay window to carry the input takeover behavior corresponding to the system input takeover area includes: The system receives touch input events applied to the system input takeover area through the transparent overlay window. Generate a corresponding system-level window operation request based on the touch input event; The system-level window operation request is isolated to prevent it from acting on the target window. Maintain the coverage of the system input takeover area by the transparent overlay window; The input takeover behavior is limited to the transparent overlay window.

9. The method according to claim 1, characterized in that, The step of constructing a continuous input event sequence based on the touch input events received by the target window according to the input event processing mechanism includes: The touch input event corresponding to the target window is received based on the input event processing mechanism. The touch input events are associated and organized according to their occurrence sequence to generate an input event chain; Based on the input event chain, the time interval between adjacent touch input events is calculated according to the timestamp information corresponding to the touch input event; The time interval is compared with a preset time threshold to determine the continuity status of the touch input event; The touch input events are organized sequentially according to the event continuity state to generate a continuous input event sequence.

10. A touch input continuity assurance system based on window overlay, characterized in that, The system includes: The target window creation module is used to create a target window and establish an input event handling mechanism corresponding to the target window; The region determination module is used to determine the system input takeover region corresponding to the target window; A transparent overlay window construction module is used to create a transparent overlay window based on the system input takeover area; An overlay structure construction module is used to construct a window overlay structure based on the transparent overlay window and the target window; The continuous protection module is used to carry the input takeover behavior corresponding to the system input takeover area using the window overlay structure, so that the target window continuously receives touch input events; A sequence construction module is used to construct a continuous sequence of input events based on the touch input events received by the target window according to the input event processing mechanism. The touch interaction processing module is used to perform touch interaction processing based on the continuous input event sequence.

Images