Input processing method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides an input processing method and device, electronic equipment and a storage medium, the method is applied to a compatible layer, and the method comprises the steps that in the process that a target input window of a target Windows application program running in the compatible layer receives a text input operation, a target message is monitored in real time; the target message comprises any one of the following messages: a mouse moving message, a mouse clicking message and a window obtaining input focus message; when the target message is monitored, acquiring a first coordinate of a current input position under a screen coordinate system of the compatible layer, and converting the first coordinate into a second coordinate under a client area coordinate system of a target input window; and converting the second coordinate into a third coordinate under the X11 top window coordinate system, and updating the input position attribute of the input context corresponding to the target input window into the third coordinate. According to the method, the position of the input method candidate box and the actual position of the input cursor can be synchronized in real time, and the input efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an input processing method, apparatus, electronic device, and storage medium. Background Technology

[0002] Wine is an open-source compatibility layer that allows Windows applications to run on Unix-like systems such as Linux and macOS. To enable Windows applications to use Input Method Editors (IMEs) correctly within the compatibility layer, the layer typically implements input functionality by interfacing with the underlying input method service.

[0003] Currently, although the input function of the input method can be implemented in the compatibility layer, when the user moves the input cursor in the input interface (such as the CAD command line), the underlying input method service cannot obtain the new cursor position, resulting in a serious misalignment between the input method candidate box and the actual cursor position. Users always need to find the candidate box first and then select the candidate text from it, which affects input efficiency and input experience. Summary of the Invention

[0004] In view of the above problems, this application proposes an embodiment to provide an input processing method that overcomes or at least partially solves the above problems, which can realize real-time synchronization between the position of the input method candidate box and the actual position of the input cursor, thereby improving input efficiency and input experience.

[0005] Accordingly, embodiments of this application also provide an input processing device, an electronic device, and a storage medium to ensure the implementation and application of the above methods.

[0006] In a first aspect, embodiments of this application disclose an input processing method applied to the Wine compatibility layer in a Linux system, the method comprising: During the text input operation received by the target input window of the target Windows application running in the compatibility layer, target messages are monitored in real time; the target messages include any of the following: mouse movement messages, mouse click messages, and window gaining input focus messages. When the target message is detected, the first coordinate of the current input position in the screen coordinate system of the compatibility layer is obtained, and the first coordinate is converted into the second coordinate in the client area coordinate system of the target input window; The second coordinate is converted to a third coordinate in the X11 top-level window coordinate system, and the input position attribute of the input context corresponding to the target input window is updated to the third coordinate.

[0007] Secondly, embodiments of this application disclose an input processing apparatus, characterized in that it is applied to a compatibility layer in a Linux system, the apparatus comprising: The message monitoring module is used to monitor target messages in real time during the text input operation of the target input window of the target Windows application running in the compatibility layer; the target messages include any of the following: mouse movement messages, mouse click messages, and window gaining input focus messages; The coordinate transformation module is used to, when the target message is detected, obtain the first coordinate of the current input position in the screen coordinate system of the compatibility layer, and convert the first coordinate into the second coordinate in the client area coordinate system of the target input window; and convert the second coordinate into the third coordinate in the X11 top-level window coordinate system; The attribute update module is used to update the input position attribute of the input context corresponding to the target input window to the third coordinate.

[0008] Thirdly, embodiments of this application disclose an electronic device, including: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, which causes the processor to perform the steps of any of the input processing methods described above.

[0009] Fourthly, embodiments of this application disclose a readable storage medium storing a program or instructions, which, when executed by a processor, can implement any of the input processing methods described in the embodiments of this application.

[0010] The input processing method, apparatus, electronic device, and storage medium provided in the embodiments of this application have the following advantages: When a user performs text input in the target input window of a target Windows application running in Wine, this application can detect changes in the input cursor position by monitoring target messages in real time. This triggers an automatic update mechanism to obtain the current actual position of the input cursor and automatically update the input position attribute of the input context corresponding to the target input window. This ensures that the position of the input method candidate box is synchronized with the actual position of the input cursor in real time. Whether the mouse moves, the input cursor jumps, or the window focus changes, the input method candidate window can accurately appear at the input cursor position, rather than being fixed in the upper left corner of the screen or appearing in the wrong position, thus improving user input efficiency. Furthermore, this application makes the input method in compatibility layers such as Wine more similar to the native Windows system, improving the usability and popularity of cross-platform software. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating the steps of an embodiment of the input processing method of this application; Figure 2 This is a flowchart illustrating the steps of an example of an input processing method embodiment in this application; Figure 3 This is a structural block diagram of an embodiment of an input processing device according to this application; Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0012] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0013] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and are not limited in number; for example, a first object can be one or more. Furthermore, the term "and / or" in the specification and claims is used to describe the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0014] First, the key terms involved in this application will be explained.

[0015] Wine is an open-source compatibility layer that allows Windows applications to run on Unix-like systems such as Linux and macOS.

[0016] IME (Input Method Editor): This is middleware or framework built into the Windows system. It defines the rules for communication between the input method, the operating system, and applications. It provides pre-editing and conversion mechanisms, allowing users to input non-alphabetic characters (such as Chinese, Japanese, Korean, etc.) or complex characters using a standard keyboard. User keystrokes are first received by the IME, converted into one or more temporary, undetermined candidate words, and after user interaction and selection, submitted as the final text to the application for display.

[0017] XIM (X Input Method, X Window System Input Method Framework) is a protocol and framework in X11 (X Window System) for supporting complex text input in a client-server architecture. It defines the rules for communication between applications (clients) running in the X11 environment and independent input method services (servers), enabling interactive input of non-alphabetic characters (such as Chinese, Japanese, and Korean). X11 is an independent, cross-platform window system protocol and the foundation for the graphical display of most Linux desktop environments. Input method services include IBus and Fcitx.

[0018] IBus (Intelligent Input Bus) is a modular, open-source Linux / Unix input method framework. Employing a bus-based architecture, it acts as a central scheduling and communication hub between the input method engine, applications, and the operating system, aiming to provide unified, efficient, and intelligent text input services.

[0019] Fcitx (Free Chinese Input Toy for X11, the Little Penguin Input Method Framework): Similar to IBus, it is also a mainstream open-source input method framework on Linux / Unix systems.

[0020] XIC (X Input Context): In the XIM protocol, this is a context object used to represent an independent input session, bridging the state and string transmission between the Linux input method framework and the Windows message input mechanism. The XIC's input location property (XNSpotLocation property) specifies the display position of the input method candidate box in the X11 top-level window.

[0021] Figure 1 This illustration shows a flowchart of an embodiment of an input processing method according to this application. The method can be applied to the compatibility layer of a Linux system and may include the following steps: Step 101: During the process of receiving text input operations in the target input window of the target Windows application running in the compatibility layer, monitor target messages in real time; the target messages include any of the following: mouse movement messages, mouse click messages, and window gaining input focus messages; Step 102: When the target message is detected, obtain the first coordinates of the current input position in the screen coordinate system of the compatibility layer, and convert the first coordinates into the second coordinates in the client area coordinate system of the target input window; Step 103: Convert the second coordinate to the third coordinate in the X11 top-level window coordinate system, and update the input position attribute of the input context corresponding to the target input window to the third coordinate.

[0022] The input processing method provided in this application can be applied to electronic devices based on the Linux operating system. These electronic devices may include, but are not limited to, any of the following: servers, smartphones, voice recorders, tablets, e-book readers, MP3 (Moving Picture Experts Group Audio Layer III) players, MP4 (Moving Picture Experts Group Audio Layer IV) players, laptops, in-vehicle computers, desktop computers, set-top boxes, smart TVs, wearable devices, etc.

[0023] This application does not limit the type of Linux operating system. For example, the Linux operating system may include, but is not limited to, any one of Debian, Ubuntu, CentOS (Community Enterprise Operating System), UOS (Tongxin Desktop Operating System), Kylin Operating System, Fangde Operating System, etc.

[0024] The Linux system described herein runs a compatibility layer that allows Windows applications to run. The input processing method provided in this application enables real-time synchronization between the input method candidate box and the input cursor position in the Windows application within the compatibility layer. The input cursor refers to a visual marker in the text input interface that indicates the current text insertion position. In this application, it is also simply referred to as the cursor. This application does not limit the type of the compatibility layer; for example, the compatibility layer could be Wine or CrossOver. This application uses Wine as an example for illustration.

[0025] In order for Windows applications to use the Input Method Editor (IME) properly in a compatibility layer (such as Wine), the compatibility layer bridges to the input method service (such as IBus or Fcitx) of the host system (such as Linux) through the XIM protocol to implement input functionality.

[0026] For example, when a user performs a text input operation in the target input window of a target Windows application running in Wine, X11, as the underlying window system, provides the basic input event transmission capability. Linux native input method services such as IBus and Fcitx receive the user's key events through the XIM protocol, and generate one or more candidate words according to the key sequence. For example, the key sequence "nihao" can generate candidate words such as "你好" (hello) and "拟好" in Chinese input. The candidate words are displayed in the input method candidate box in list form. Wine acts as an intermediate adaptation layer. On the one hand, it interacts with input method services such as IBus and Fcitx through the XIM protocol to obtain the final character selected by the user from the candidate words. On the other hand, it simulates the IME interface of Windows, converts the final character into the Windows IME message format, and finally passes it to the target Windows application for display.

[0027] The target Windows application is any Windows application that can receive text input operations running in Wine.

[0028] When a user triggers a text input operation in the target input window of the target Windows application, Wine creates (if not created yet) or obtains (if already created) a corresponding input context (XIC) for the target input window by calling the interface provided by the XIM protocol. The position of the input method candidate box depends on the input position attribute (XNSpotLocation attribute) of this XIC for setting. When the user moves the input cursor within the target input window, the input method service (such as IBus or Fcitx, etc.) cannot obtain the actual position of the input cursor, and thus will not update the XNSpotLocation attribute of the XIC corresponding to the target input window in real time, resulting in a dislocation between the position of the input method candidate box and the actual position of the input cursor, affecting the input efficiency.

[0029] To solve the above problems, during the process of a user performing a text input operation in the target input window of a target Windows application running in Wine, this application can detect a change in the input cursor position by real-time monitoring of the target message. When the input cursor position changes, the corresponding target message can be intercepted, thereby triggering an automatic update mechanism (steps 102 and 103), automatically obtaining the current actual position of the input cursor and updating the XNSpotLocation attribute of the XIC corresponding to the target input window, so as to achieve real-time synchronization between the position of the input method candidate box and the actual position of the input cursor. In addition, this application implements an input cursor position update mechanism driven by message events, avoiding polling overhead and improving the response efficiency of the input method.

[0030] It should be noted that an input window refers to a window with text input functionality. For example, input windows include, but are not limited to, text boxes, command lines, Notepad editing areas, and browser address bars. The target input window refers to the input window in which the user is currently performing text input operations.

[0031] The target message refers to a Windows message triggered when the position of the input cursor changes. This application embodiment does not limit the type of the target message. For example, the target message includes, but is not limited to, any of the following: mouse movement message, mouse click message, and window gaining input focus message.

[0032] Among them, the mouse movement message includes WM_MOUSEMOVE, which is used to reposition the input method candidate box when the mouse moves.

[0033] Mouse click messages include WM_LBUTTONDOWN (left mouse click), WM_RBUTTONDOWN (right and left mouse click), and WM_MBUTTONDOWN (middle mouse click), which are used to reposition the input method candidate box when the mouse is clicked.

[0034] The window gains input focus message, including WM_SETFOCUS, which is used to reposition the input method candidate box when the window gains input focus.

[0035] When this application detects any of the aforementioned target messages, it indicates that the position of the input cursor has changed during the user's text input process. At this time, it obtains the first coordinates of the current input position in the screen coordinate system of the compatibility layer. The current input position is the position of the current input cursor.

[0036] Since the Windows application runs in the compatibility layer Wine environment, the coordinates of the current input position are the coordinates of that position in the screen coordinate system of the compatibility layer, referred to as the first coordinates. First, the first coordinates are converted to the second coordinates in the client area coordinate system of the target input window, and then the second coordinates are converted to the third coordinates in the X11 top-level window coordinate system.

[0037] Since the input method service runs at the X11 server level, while Windows applications use the Windows client area coordinate system, coordinate mapping is required. This application performs two coordinate transformations on the current input position. The first transformation is from the screen coordinate system of the compatibility layer to the client area coordinate system of the target input window. The second transformation is from the client area coordinate system of the target input window to the X11 top-level window coordinate system. These two transformations belong to two different coordinate systems, each addressing a different level of positioning.

[0038] The screen coordinate system of the compatibility layer is a virtual, complete desktop coordinate space maintained by the compatibility layer (such as Wine). It provides a unified coordinate reference system consistent with the native Windows desktop concept for all Windows applications running within it. The origin is located at the top-left corner of the Wine virtual desktop. This origin may not be the same as the origin of the physical screen (for example, when Wine is running in windowed mode).

[0039] The client area coordinate system of the target input window is the local coordinate system of the specific window (target input window) within the target Windows application that receives input focus. It is used to describe the relative positions of elements within the target input window. The origin is located at the top-left corner of the target input window. Each window has its own client area coordinate system, with its origin located at its own top-left corner.

[0040] The X11 top-level window coordinate system is a coordinate reference system in the Linux graphics system (X11) used to precisely position and draw graphical elements (including cursors, windows, candidate boxes, etc.) on the physical screen. Its core function is to allow the X11 server to know which pixel on the screen should be used to perform the drawing operation. The first coordinate transformation is used within the compatibility layer to determine the precise location of the current input position within the target input window. This transformation converts the cursor position to a coordinate system that the Windows application can understand (its position within the target input window) for Wine to use. Through this first coordinate transformation, Wine knows "where the cursor is within the target input window."

[0041] The second coordinate transformation is used to map the "specific position of the input cursor within the target input window" to the X11 top-level window coordinate system, that is, to map the position of the input cursor to the specific position on the actual physical screen, so that the input method service (such as IBus or Fcitx) knows where to draw the input method candidate box on the physical screen.

[0042] According to the XIM protocol specification, the XNSpotLocation property should be set based on the X11 top-level window coordinate system. Since the Windows application running Wine uses the client area coordinate system internally, if it is not converted to the X11 top-level window coordinate system, the XIM input method candidate box will not be aligned with the internal position of the Windows application. This will cause a deviation between the position of the input method candidate box and the position of the input cursor, or cause the position of the input method candidate box to always be fixed at the origin (0,0) (such as the upper left corner of the screen). Therefore, to match the coordinate reference required by the XIM protocol, a second coordinate transformation converts the second coordinate in the client area coordinate system used internally by the Windows application to a position relative to the X11 top-level window (whole_rect). This allows the input method service to locate the position of the input candidate box based on a unified coordinate reference, ensuring that the input method candidate box is positioned at the current input position regardless of whether the trigger source is a change in the mouse, keyboard, or input cursor position.

[0043] After two coordinate transformations, the input position attribute (XNSpotLocation attribute) of the input context (XIC) corresponding to the target input window is updated to the third coordinate.

[0044] Furthermore, the method may also include: The input method service is notified that the input position attribute of the target input window has been updated, so that the input method service displays the input method candidate box according to the position indicated by the updated input position attribute.

[0045] After updating the XNSpotLocation property of the XIC corresponding to the target input window to the third coordinate, the input method service (such as IBus or Fcitx) can be notified. The input method service can then display the input method candidate box based on the position indicated by the updated XNSpotLocation property, achieving real-time synchronization between the position of the input method candidate box and the actual position of the input cursor. Because the coordinates recorded by the XNSpotLocation property are the actual position of the input cursor and have been precisely converted to the X11 top-level window coordinate system, the input method candidate box will not experience offset, misalignment, or be fixed to the upper left corner of the screen.

[0046] In one optional embodiment of this application, obtaining the first coordinates of the current input position in the screen coordinate system of the compatibility layer and converting the first coordinates into a second coordinate in the client area coordinate system of the target input window may include: Step S11: Obtain the current GUI (Graphical User Interface) thread information of the target Windows application, and determine whether the target handle in the current GUI thread information is valid; the target handle points to the window with the active caret. Step S12: If the target handle is valid, obtain the first coordinate of the active caret and convert the first coordinate of the active caret into the second coordinate; Step S13: If the target handle is invalid, obtain the first coordinate of the current mouse and convert the first coordinate of the current mouse into the second coordinate.

[0047] When determining the current input position, this application prioritizes the position of the active caret as the current input position. The active caret, in a graphical user interface, is the visual cursor within the input window that currently has input focus, indicating the next character to be inserted; it is also called the input cursor. This visual cursor indicates that the position is the only text insertion point ready to receive direct keyboard input or input method conversion results. Throughout the entire desktop session, only one text caret can be active at any given time, and it must always appear within the input window that currently has input focus.

[0048] Specifically, the current GUI thread information of the target Windows application can be obtained, and it can be determined whether the target handle (hwndCaret) in the current GUI thread information is valid; the target handle points to the window with the active caret. The current GUI thread is the GUI thread in the target Windows application responsible for handling window messages and managing all window messages of the target Windows application.

[0049] If the target handle hwndCaret is valid, it means that there is a window with an active caret in the current GUI thread, and hwndCaret points to that window. This window is the input window with the active caret and can receive text input. At this time, the first coordinate of the active caret can be obtained and converted into the second coordinate.

[0050] If the target handle hwndCaret is invalid, i.e. hwndCaret is NULL or an invalid handle, it means that no window in the current GUI thread has an active caret. An invalid hwndCaret may be caused by one of the following reasons: (1) The target Windows application does not use the standard Windows active caret, such as the target Windows application being CAD, a game, or graphics software; (2) The target input window uses a custom-drawn control and has not created and associated a text caret; (3) The target input window has just gained input focus, but the text caret has not yet been displayed; (4) The input focus is on a non-text control such as a button or list box.

[0051] If the target handle hwndCaret is invalid, as an alternative, the current mouse position can be used as the current input position. In this case, the first coordinate of the current mouse can be obtained and converted into a second coordinate. The current mouse position refers to the position of the current mouse pointer / cursor.

[0052] This application does not limit the method for obtaining the current GUI thread information of the target Windows application. For example, NtUserGetGUIThreadInfo is a system function in Windows that obtains GUI thread information. Wine, in its internally implemented user-level dynamic link library (such as win32u.dll), simulates the Windows system's NtUserGetGUIThreadInfo function (referred to as the first simulated function), and by calling this function, the current GUI thread information of the target Windows application can be obtained.

[0053] This application does not limit the method for obtaining the first coordinates of the active caret. For example, NtUserGetCaretPos is a system function in Windows that obtains the active caret. Wine, in its internally implemented user-level dynamic link library (such as win32u.dll), simulates the Windows system's NtUserGetCaretPos function (referred to as the second simulated function), and the first coordinates of the active caret can be obtained by calling this function.

[0054] This application does not limit the method for converting the first coordinate to the second coordinate. For example, NtUserMapWindowPoints is a system function in Windows that converts coordinates in one window coordinate system (such as the first coordinate) to coordinates in another window coordinate system (such as the second coordinate). Wine, in its internally implemented user-level dynamic link library (such as win32u.dll), simulates the Windows system's NtUserMapWindowPoints function (called the third simulated function), which can be called to convert the first coordinate to the second coordinate. For example, if the target handle hwndCaret is valid, calling this function converts the first coordinate of the active caret to the second coordinate; if the target handle hwndCaret is invalid, calling this function converts the first coordinate of the current mouse cursor to the second coordinate.

[0055] In one optional embodiment of this application, updating the input position attribute of the input context corresponding to the target input window to the third coordinate may include: Step S21: Set the value of the preset global variable to the third coordinate, and set the value of the preset global identifier to the target value; Step S22: Obtain the input context corresponding to the target input window by calling the first interface provided by the compatibility layer; Step S23: Write the value of the preset global variable into the input position attribute of the input context corresponding to the target input window.

[0056] Furthermore, this application updates the input position attribute of the input context corresponding to the target input window to the third coordinate, introduces a preset global variable to record the third coordinate, and uses a preset global identifier to record the state of the preset global variable.

[0057] Specifically, the value of the preset global variable is set to the third coordinate, and the value of the preset global identifier is set to the target value (e.g., TRUE). The value of the preset global identifier as the target value indicates that the value recorded in the preset global variable is valid.

[0058] The input context corresponding to the target input window can be obtained by calling the first interface provided by the compatibility layer. For example, the first interface is `xim_lookup_ic(hwnd)`, where the parameter `hwnd` is the handle of the target input window. By calling the first interface, the input context `XIC` corresponding to the target input window can be obtained, and then the value of the preset global variable can be written to the input position attribute of this input context, completing the update of the `XNSpotLocation` attribute of the `XIC` corresponding to the target input window.

[0059] This application accurately obtains the current input position when the user's input position changes during the input process in a Windows application running Wine, performs coordinate transformation, and actively updates the XNSpotLocation property of the XIM input context (XIC) to ensure that the position of the input method candidate box is kept synchronized with the current input position in real time.

[0060] In one optional embodiment of this application, the method may further include: Step S31: When creating the input context corresponding to the target input window, read the value of the preset global identifier; Step S32: If the value of the preset global identifier is the target value, then read the value of the preset global variable as the initial coordinates; the preset global variable is used to record the value of the input position attribute of the last update; Step S33: If the value of the preset global identifier is not the target value, then calculate the third coordinate of the active caret as the initial coordinate; Step S34: Initialize the input position attribute of the input context corresponding to the target input window to the initial coordinates.

[0061] This application introduces a preset global variable to record the third coordinate, and the preset global variable can be used to cache the position of the most recently valid input cursor for reuse when creating a new input context.

[0062] When an input window in Wine first acquires an active caret (ready to receive text input), Wine creates a corresponding input context (XIC) for that input window by calling the `xic_create()` interface provided by the XIM protocol. When initializing the `XNSpotLocation` property of this XIC, the value of a preset global variable can be used for initialization. Specifically, the value of the preset global variable is read; if it is the target value (e.g., TRUE), it means that the preset global variable records a valid value, that is, the third coordinate used in the last update of the `XNSpotLocation` property. At this point, the value of the preset global variable can be read as the initial coordinate, and the `XNSpotLocation` property of the input context (XIC) created in step S31 can be initialized to this initial coordinate.

[0063] If the value of the preset global identifier read is not the target value, it means that the preset global variable has not yet cached the position of the valid input cursor. Then, the third coordinate of the active caret (input cursor) is calculated in real time as the initial coordinate, and the XNSpotLocation property of the input context XIC created in step S31 is initialized to this initial coordinate.

[0064] When creating the input context XIC corresponding to the input window, this application uses the previously updated input cursor position cached by a pre-set global variable or the current input cursor position calculated in real time to initialize the XNSpotLocation property of the newly created input context XIC, which can avoid position errors when the input method candidate box is first displayed.

[0065] In one optional embodiment of this application, the method may further include: Step S41: Receive the first encoded string submitted by the input method service for the candidate words selected by the user; Step S42: Convert the first encoded string into a second encoded string that conforms to the Windows system; Step S43: Submit the second encoded string to the message queue corresponding to the target window so that the target window receives and displays it in sequence.

[0066] When a user finally confirms their input (commit) in the input method interface, for example, by selecting and submitting a candidate word, this candidate word is generated by the input method service and passed to Wine as a first encoded string in UTF-8 encoding. Upon receiving this first encoded string from the input method service, Wine converts it to an encoding format compatible with the Windows system, such as the native Unicode encoding format used by Windows, resulting in a second encoded string. Subsequently, Wine's message processing mechanism simulates and triggers a series of Windows IME event messages, submitting the converted second encoded string to the message queue corresponding to the target window. This allows the target window to receive and display text input sequentially, just as in a native Windows environment. The target window can include the target input window or the currently focused window.

[0067] For input methods of non-Latin languages, there are usually two stages: preedit and commit.

[0068] Pre-edit refers to the temporary editing stage before the user confirms the input. At this time, the characters entered (such as Pinyin, Wubi code, kana, etc.) will be displayed in a temporary, underlined area (i.e., the pre-editing area), and may be accompanied by a list of candidate words for the user to choose from.

[0069] "Commit" refers to the user's final confirmation of the input. When the user selects a candidate word from the candidate box or presses Enter to confirm the current input, the pre-editing state ends, and the finalized text is submitted to the application.

[0070] This application ensures that the actual position of the input cursor is transmitted to the input method service in real time, ensuring that the preedit process and the commit process are visible and accurately synchronized. This avoids the problem of the preedit area not being displayed or the input method candidate box being in the wrong position when using the input method in Wine, which leads to commit chaos.

[0071] In one optional embodiment of this application, submitting the second encoded string to the message queue corresponding to the target window may include: Step S51: Determine whether the target input window is the focus window; Step S52: If the target input window is the focused window, then by calling the second interface provided by the compatibility layer, the second encoded string is submitted to the message queue corresponding to the target input window; Step S53: If the target input window is not the focus window, the focus window is determined by calling the third interface provided by the compatibility layer, and the second encoded string is submitted to the message queue corresponding to the focus window by calling the second interface provided by the compatibility layer.

[0072] Further, submitting the second encoded string to the message queue corresponding to the target window may include: Step S54: If the target Windows application does not support input method messages, the second encoded string is submitted character by character to the message queue corresponding to the target window.

[0073] To enhance the cross-application compatibility of the method in this application, a three-level message submission strategy is adopted to submit the second encoded string to the message queue corresponding to the target window. The three-level message submission strategy refers to providing the following three message submission paths: main path, executing step S52; secondary path, executing step S53; and fallback path, executing step S54.

[0074] Under normal circumstances, that is, when the target input window is the focused window and the target Windows application supports input method messages, messages are submitted to the message queue corresponding to the target input window through the main path.

[0075] In Windows systems, keyboard input events (including character input generated and forwarded by the IME) must ultimately be received and processed by the window that has input focus (called the focus window). Therefore, the second encoded string should be submitted to the message queue corresponding to the focus window.

[0076] This application determines whether the target input window is the focused window and whether the target Windows application supports input method messages (i.e., IME messages). The reason for determining whether the target Windows application supports IME messages is that some traditional applications may not support IME messages. If a second encoded string is transmitted via IME messages, these applications may be unable to receive and correctly display the input text.

[0077] If the target input window is determined to be the focused window, and the target Windows application supports IME messages, then the message is submitted via the main path. Specifically, the second encoded string is submitted to the message queue corresponding to the target input window by calling the second interface provided by the compatibility layer (such as post_ime_update).

[0078] If the input window is determined not to be the focus window—for example, in some older software or multi-window software (such as CAD) where hidden input controls may be used, or in complex software like CAD where the input focus may be in the drawing area (a window that does not directly support text input), while the actual text needs to be inserted into an edit box or property panel in a command line (the actual input window)—then the text entered by the user in the command line should be displayed in the focus window (drawing area), not in the input window. Therefore, if the target input window (command line) is determined not to be the focus window, and the target Windows application (CAD) supports IME messages, the message is submitted via a secondary path. Specifically, the focus window is determined by calling a third interface (such as get_focus) provided by the compatibility layer. The third interface can return the handle of the currently focus window (such as the drawing area window). Then, by calling the second interface, the second encoded string is submitted to the message queue corresponding to the focus window (such as the drawing area window), allowing the focus window to display the user-inputted text content sequentially.

[0079] If it is determined that the target Windows application does not support IME messages, a message is submitted to the message queue corresponding to the target window via a fallback path. Specifically, the second encoded string is submitted character by character (e.g., WM_CHAR) to the message queue corresponding to the target window one by one.

[0080] This application provides a three-level message submission strategy: main path, secondary path, and fallback path. The main path is for scenarios where the target input window is the currently focused window and the target Windows application supports IME messages. The main path is the standard and most complete input method message path. The secondary path is for non-focused windows that may require state synchronization, and these non-focused windows still belong to the input context. The secondary path is used for synchronization, bypass notification, and preventing message loss. The fallback path is for input windows that do not support the IME message mechanism (e.g., programs that only handle key events). The fallback path serves as a fallback by simulating keyboard events, text input, etc. This application uses a capability-adaptive multi-level dispatch model with the main path as the standard IME channel, the secondary path as a state / compatibility aid, and the fallback path as a final fallback mechanism. By judging the focus state of the target input window and its support capability for input method messages, the main path, secondary path, or fallback path can be selectively triggered, ensuring that messages carrying a second encoded string can be stably and accurately delivered to the corresponding windows in different application scenarios, thus guaranteeing the correctness of the input.

[0081] Furthermore, when this application detects that the target input window is not the focus window, it retains its ability to process state synchronization messages while redirecting the actual input submission message to the focus window returned by `get_focus()`, instead of sending it to the current non-focus window (the target input window). This non-focus window can still receive and process state notification messages, thus maintaining consistent awareness of its input state with the system. Simultaneously, it ensures that text input only takes effect in the focus window, thereby preventing non-focus windows from misprocessing input content.

[0082] In one optional embodiment of this application, submitting the second encoded string to the message queue corresponding to the target window may include: The second encoded string is split into characters and submitted sequentially. The characters to be submitted on different paths are compared with the characters in the target cache. If they are the same and the interval is less than a preset time, the characters to be submitted are ignored. The target cache is used to cache the characters that were last successfully submitted.

[0083] This application adopts a three-level message submission strategy and introduces character deduplication logic to prevent the same character from being entered repeatedly due to multiple paths.

[0084] At the interface level, both the primary and secondary paths can submit a single string (containing one or more characters) at a time. However, upon entering the message queue, it is broken down into individual characters and submitted one by one. Therefore, on all three paths, the encoded string is submitted to the message queue character by character. For example, if the primary or secondary path submits a single string (such as "you"), Wine's message processing mechanism will break this string down into individual characters and submit them to the message queue sequentially.

[0085] To avoid duplicate submissions from multiple different paths, this application compares the currently pending character on different paths with the character in the target cache. If they are the same and the interval is less than a preset duration, the currently pending character is ignored. The target cache (e.g., last_commit_char) is used to cache the character from the most recently successfully submitted character. The preset duration can be set according to actual needs and can be a relatively short duration to filter out multiple paths simultaneously or interleaved from submitting the same character.

[0086] The target cache can be a global variable at the character level. When the second encoded string contains multiple characters, the second encoded string is split into individual characters and submitted sequentially before being submitted to the message queue. The target cache only records the most recently successfully submitted single character.

[0087] In one example, when the user finally confirms the input (commit) of the character "你" in the input method interface, the input method service passes the first encoded string of the character "你" in UTF-8 encoding form to Wine. Wine converts it into a second encoded string in Unicode form for message submission, and compares it with the character recorded in the target cache last_commit_char before submitting each character. If the two are different, submission is allowed and last_commit_char is updated to the currently successfully submitted character. For example, after submitting the character "你" through the main path, last_commit_char is updated to the character "你". Even if the subsequent secondary path or backward path repeats the submission of this input, since the character to be submitted currently in the secondary path or backward path is the same as the character in last_commit_char, both are the character "你", so it will be automatically intercepted and ignored, and submission is not allowed, thus avoiding the repeated input of the same character by different paths. Therefore, even if multiple paths repeat the submission of the same input (such as the character "你"), the Windows application will finally receive only one character "你". Through character-by-character comparison of the character to be submitted currently on different paths with the target cache, this application can ensure that each character is submitted only once even when the same character is delivered simultaneously or alternately on the main path, secondary path, and backward path, thus avoiding the problem of repeated input caused by multi-path triggering.

[0088] It should be noted that the purpose of introducing the deduplication logic in this application is to prevent the same input result (the second encoded string) generated by the same input event from being repeatedly submitted to the same window by multiple paths, resulting in the appearance of incorrect repeated characters. For the same characters continuously input by the user (such as "哈哈哈"), they are different input events, and the input results are logically new submissions on the same path, so they will not be filtered. That is, the deduplication logic judges whether the characters submitted to the message queue by different paths at the same time are the same, and those on the same path do not need to be judged.

[0089] This application ensures that input characters are not lost and not repeated through a multi-layer guarantee mechanism, which can improve the correctness and stability of input.

[0090] Finally, the target window in the target Windows application processes the messages in its message queue sequentially, thus receiving and displaying the user-inputted text in order. This application enables the normal reception of user-inputted text across various platforms, including complex IDEs (Integrated Development Environments), CAD software, and simple text editors. Furthermore, throughout the input process, the position of the input method candidate box remains synchronized with the position of the input cursor, significantly improving the efficiency and user experience of Chinese and other complex language input in cross-platform environments.

[0091] Reference Figure 2 The flowchart illustrates the steps of an embodiment of the input processing method in one example of this application, as follows: Figure 2 As shown, the following steps may be included: Step A1: Window message capture and trigger condition identification.

[0092] Specifically, during the text input operation received by the target input window of the target Windows application running in the compatibility layer, target messages are monitored in real time. These target messages include any of the following window messages: mouse movement message, mouse click message, or window gaining input focus message. If any of these target messages is detected, the triggering condition is determined to be met, thereby triggering the automatic update mechanism and proceeding to step A2.

[0093] Furthermore, the real-time monitoring of target messages includes: intercepting multiple key mouse and focus events in the default window procedure function default_window_proc of Wine's core module win32u. These multiple key mouse and focus events include, but are not limited to: WM_MOUSEMOVE, WM_LBUTTONDOWN, WM_RBUTTONDOWN, WM_MBUTTONDOWN, and WM_SETFOCUS.

[0094] When any of the aforementioned target messages is intercepted, it is determined whether the system has registered the target callback function pUpdateIMECursorPos. This target callback function is provided by Wine's X11 graphics driver. If it has been registered, the target callback function is called, and the coordinate parameter in the currently intercepted target message is parsed into a second coordinate and passed to the target callback function. This target callback function is used to synchronously update the input cursor position changes of the Windows application to the XIM input context.

[0095] This application actively invokes the target callback function when a target message is detected, making it the entry point for driving step A2. The function of this target callback function is to forward the current client area coordinates to the X11 input method driver, thereby triggering subsequent coordinate transformation (step A2) and XNSpotLocation property update (step A3).

[0096] Step A2: Cursor position extraction and coordinate space transformation.

[0097] Since the input method service runs on the X11 server level, while Windows applications use the Windows client area coordinate system, precise coordinate mapping is required.

[0098] This application obtains the coordinates of the current input position and performs coordinate transformation in the following manner: 2-1. Prioritize retrieving the position of the active caret: The first simulation function (simulating NtUserGetGUIThreadInfo in Windows) is called to obtain the current GUI thread information and check if a valid hwndCaret exists. If hwndCaret is valid, the first coordinate of the active caret is obtained by calling the second simulation function (simulating NtUserGetCaretPos in Windows). Then, the first coordinate is converted into the client area coordinates (second coordinates) of the target input window by calling the third simulation function (simulating NtUserMapWindowPoints in Windows).

[0099] 2-2. Alternative mouse positions: If the position of the active caret cannot be obtained (hwndCaret is invalid), the current mouse position is obtained as an alternative.

[0100] 2-3. Transform the coordinate system to the X11 top-level window coordinate system: The client area coordinates obtained in step 2-1 or 2-2 are further converted to coordinates relative to the X11 top-level window (whole_rect) coordinate system to obtain a third coordinate, which matches the coordinate reference required by the XIM protocol. This process ensures that the input method candidate box can be accurately positioned at the actual input location regardless of whether the user triggers input through the keyboard or mouse.

[0101] Step A3: Update the XNSpotLocation property of the input method context (XIC).

[0102] Furthermore, this application introduces a pre-defined global variable g_spot_location and a pre-defined global flag g_spot_location_valid to cache the most recently valid input position for reuse when creating a new input context.

[0103] Furthermore, this application updates the XNSpotLocation property of the input method context (XIC) by calling a custom function. The custom function, such as xim_update_cursor_pos, specifically performs the following operations: 3-1. Update the global cursor hotspot position; specifically, write the third coordinate calculated in step A2 into g_spot_location, and set g_spot_location_valid to the target value, such as TRUE.

[0104] 3-2. Obtain the XIC corresponding to the target input window; specifically, obtain the XIC corresponding to the target input window by calling the first interface xim_lookup_ic(hwnd).

[0105] 3-3. Update the XNSpotLocation property in the XIC returned in step 3-2 by calling the XSetICValues ​​function, and update its value to the third coordinate.

[0106] This mechanism enables input method services such as IBus and Fcitx to display the input method candidate box in the correct position based on the XNSpotLocation property, achieving real-time synchronization between the input method candidate box and the input cursor position.

[0107] It should be noted that after calling pUpdateIMECursorPos in step A1, step A3 is ultimately executed by calling xim_update_cursor_pos.

[0108] Step A4: Precise rendering of the input method candidate box.

[0109] After updating the XNSpotLocation property of the XIC corresponding to the target input window, the input method service is notified to render the input method candidate box at the new location. Based on the updated XNSpotLocation property, the input method service can adjust the display position of the input method candidate box in real time. Because the third coordinate recorded in the XNSpotLocation property has been accurately transformed to the X11 top-level window coordinate system, the input method candidate box will not experience offset, misalignment, or be fixed to the upper left corner of the screen.

[0110] For example, after entering "Hello", the input caret will automatically move, such as moving to after the character "好" (hao). This will trigger an internal call in the input window to update the caret. The change in the caret will trigger the WM_MOUSEMOVE or related position update message. Therefore, it will return to step A1 to re-execute the process of this application. Thus, in the case where the position of the input caret changes due to user input, moving the cursor, clicking the mouse, etc., the actual position of the input caret will be repositioned in real time, and the XNSpotLocation property of the XIC corresponding to the target input window will be updated in real time.

[0111] In addition, when creating an input context for the input window, this application preferentially uses the previously cached cursor position or attempts to obtain the initial caret position to avoid incorrect positions during the first input.

[0112] Step A5: Receiving and processing of the input result.

[0113] When the user confirms the input (commit) in the input method interface, Wine receives the first encoded string in UTF-8 form submitted by the input method service. After being converted into a second encoded string in Unicode form, it is submitted to the message queue of the target window in Wine through post_ime_update(), triggering standard Windows IME messages such as WM_IME_COMPOSITION.

[0114] Step A6: Multi-level message dispatching and anti-duplication mechanism.

[0115] To enhance cross-application compatibility, this application adopts a three-level message submission strategy: 6-1. Main path: Through the standard IME interface post_ime_update(), submit an IME message carrying the input result (the second encoded string) to the message queue corresponding to the target input window; 6-2. Secondary path: If the target input window is a non-focus window, submit an IME message carrying the input result to the message queue corresponding to the focus window returned by get_focus(); 6-3. Fallback path: For applications that do not support IME messages, submit the input result character by character in the form of WM_CHAR to the message queue corresponding to the target window. When the target input window is the focus window, the target window is the said target input window; when the target input window is a non-focus window, the target window is the focus window returned by calling get_focus().

[0116] At the same time, a character de-duplication logic is introduced to prevent the same character from being repeatedly input due to multiple paths.

[0117] Step A7: The target Windows application correctly receives text input.

[0118] Ultimately, whether it's a complex IDE, CAD software, or a simple text editor, all can receive the text content entered by the user normally. Moreover, throughout the entire input process, the position of the input method candidate box is always synchronized with the position of the input cursor, greatly improving the input experience of Chinese and other complex languages ​​in a cross-platform environment.

[0119] The execution flow of the method in this application is illustrated below with a specific example. Taking running AutoCAD in the Wine environment and entering Chinese characters in its command line window as an example, the specific execution flow is as follows: (1) Event capture; When a user clicks on the text input area of ​​an AutoCAD text input box, the Wine runtime environment improved in this application captures the WM_SETFOCUS and WM_MOUSEMOVE window messages, thereby triggering the input cursor position update mechanism.

[0120] (2) Obtaining the cursor position; The system calls NtUserGetGUIThreadInfo to obtain the current GUI thread information and uses hwndCaret to determine whether the AutoCAD text input box has an active caret. If so, it calls NtUserGetCaretPos to obtain the first coordinate of the active caret, and then calls NtUserMapWindowPoints to convert the first coordinate to the second coordinate and the second coordinate to the third coordinate.

[0121] (3) Input context update; The `xim_update_cursor_pos()` interface is called to write the converted third coordinates into the preset global variable `g_spot_location`, and `g_spot_location_valid` is set to `TRUE`. Then, the `XNSpotLocation` property of the XIC corresponding to the text input box is updated to the third coordinates by calling `XSetICValues`. Finally, the input method service (such as IBus or Fcitx) is notified to render the input method candidate box at the new location.

[0122] (4) The input method candidate box follows the input cursor in real time; During user input, the input method candidate box always follows the input cursor in the command line and adjusts its position in real time as the input cursor moves, achieving a "what you see is what you get" input experience and improving input efficiency.

[0123] (5) Input result injection; After the user selects a candidate word, the input method service submits a first UTF-8 encoded string, which is converted to Unicode to obtain a second encoded string. This second encoded string is then injected into the text input box via the WM_IME_COMPOSITION message. If AutoCAD does not support IME messages, the service falls back to sending WM_CHAR characters one by one. A message deduplication mechanism is used to prevent duplicate input.

[0124] (6) The input results are displayed correctly.

[0125] AutoCAD successfully received and parsed the input results, and displayed them correctly in the text input box.

[0126] In summary, when a user performs text input in the target input window of a target Windows application running in Wine, this application can detect changes in the input cursor position by monitoring target messages in real time. This triggers an automatic update mechanism to obtain the current actual position of the input cursor and automatically update the input position attribute of the input context corresponding to the target input window. This achieves real-time synchronization between the position of the input method candidate box and the actual position of the input cursor. Whether the mouse moves, the input cursor jumps, or the window focus switches, the input method candidate window can accurately appear at the input cursor position, rather than being fixed in the upper left corner of the screen or appearing in the wrong position, thus improving user input efficiency. Furthermore, this application makes the input method in compatibility layers such as Wine more similar to the native Windows system, improving the usability and popularity of cross-platform software.

[0127] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of this application.

[0128] Reference Figure 3 This diagram illustrates a structural block diagram of an embodiment of an input processing device according to this application. The system is applied to Wine, a compatibility layer in a Linux system. The device may include: The message monitoring module 301 is used to monitor target messages in real time during the text input operation received by the target input window of the target Windows application running in the compatibility layer; the target messages include any one of the following: mouse movement messages, mouse click messages, and window gaining input focus messages; The coordinate transformation module 302 is used to, when the target message is detected, obtain the first coordinate of the current input position in the screen coordinate system of the compatibility layer, and convert the first coordinate into the second coordinate in the client area coordinate system of the target input window; and convert the second coordinate into the third coordinate in the X11 top-level window coordinate system; The attribute update module 303 is used to update the input position attribute of the input context corresponding to the target input window to the third coordinate.

[0129] Optionally, the coordinate transformation module includes: The first judgment submodule is used to obtain the current GUI thread information of the target Windows application and determine whether the target handle in the current GUI thread information is valid; the target handle points to the window with the active caret. The first acquisition and conversion submodule is used to acquire the first coordinate of the active caret if the target handle is valid, and convert the first coordinate of the active caret into the second coordinate; The second acquisition and conversion submodule is used to acquire the first coordinate of the current mouse if the target handle is invalid, and convert the first coordinate of the current mouse into the second coordinate.

[0130] Optionally, the attribute update module includes: The global settings submodule is used to set the value of the preset global variable to the third coordinate and set the value of the preset global identifier to the target value; The context acquisition submodule is used to obtain the input context corresponding to the target input window by calling the first interface provided by the compatibility layer; The attribute setting submodule is used to write the value of the preset global variable into the input position attribute of the input context corresponding to the target input window.

[0131] Optionally, the device further includes: The context creation module is used to read the value of a preset global identifier when creating the input context corresponding to the target input window; The coordinate reading module is used to read the value of the preset global variable as the initial coordinate if the value of the preset global identifier is the target value; the preset global variable is used to record the value of the input position attribute of the last update; The coordinate calculation module is used to calculate the third coordinate of the active caret as the initial coordinate if the value of the preset global identifier is not the target value. The coordinate initialization module is used to initialize the input position attribute of the input context corresponding to the target input window to the initial coordinates.

[0132] Optionally, the device further includes: The notification update module is used to notify the input method service that the input position attribute of the target input window has been updated, so that the input method service can display the input method candidate box according to the position indicated by the updated input position attribute.

[0133] Optionally, the device further includes: The encoded string receiving module is used to receive the first encoded string submitted by the input method service for the candidate words selected by the user. The encoding string conversion module is used to convert the first encoded string into a second encoded string that conforms to the Windows system. The encoded string submission module is used to submit the second encoded string to the message queue corresponding to the target window, so that the target window receives and displays it in sequence.

[0134] Optionally, the encoded string submission module includes: The second judgment submodule is used to determine whether the target input window is the focus window; The first path submission submodule is used to submit the second encoded string to the message queue corresponding to the target input window by calling the second interface provided by the compatibility layer if the target input window is the focused window. The second path submission submodule is used to determine the focus window by calling the third interface provided by the compatibility layer if the target input window is not the focus window, and to submit the second encoded string to the message queue corresponding to the focus window by calling the second interface provided by the compatibility layer.

[0135] Optionally, the encoded string submission module includes: The third path submission submodule is used to submit the second encoded string character by character to the message queue corresponding to the target window if the target Windows application does not support input method messages.

[0136] Optionally, the encoded string submission module includes: The deduplication filtering submodule is used to split the second encoded string into characters and submit them sequentially, and compare the currently submitted characters on different paths with the characters in the target cache. If they are the same and the interval is less than a preset time, the currently submitted characters are ignored. The target cache is used to cache the most recently successfully submitted characters.

[0137] The input processing device provided in this application, when a user performs text input operations in the target input window of a target Windows application running in Wine, can detect changes in the input cursor position by monitoring target messages in real time. This triggers an automatic update mechanism to obtain the current actual position of the input cursor and automatically update the input position attribute of the input context corresponding to the target input window, thereby achieving real-time synchronization between the position of the input method candidate box and the actual position of the input cursor. Whether the mouse moves, the input cursor jumps, or the window focus switches, the input method candidate window can accurately appear at the input cursor position, rather than being fixed in the upper left corner of the screen or appearing in an incorrect position, which can improve user input efficiency. Furthermore, this application makes the input method in compatibility layers such as Wine more similar to the native Windows system, improving the usability and popularity of cross-platform software.

[0138] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0139] Reference Figure 4 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device includes: a processor, a memory, a communication interface, and a communication bus. The processor, the memory, and the communication interface communicate with each other through the communication bus. The memory is used to store at least one executable instruction, which causes the processor to perform the steps of the input processing method of the aforementioned embodiment.

[0140] This application provides a non-transitory computer-readable storage medium that, when the instructions in the storage medium are executed by a program or processor of a terminal, enables the terminal to perform the steps of the input processing method described in the foregoing embodiments.

[0141] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0142] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0143] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0144] These computer program instructions may also be stored in a computer-readable storage medium capable of directing a computer or other programmable data processing terminal device to operate in a predictive manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0145] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0146] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0147] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. An input processing method, characterized in that, The method, applied to a compatibility layer in a Linux system, includes: During the text input operation received by the target input window of the target Windows application running in the compatibility layer, target messages are monitored in real time; the target messages include any of the following: mouse movement messages, mouse click messages, and window gaining input focus messages. When the target message is detected, the first coordinate of the current input position in the screen coordinate system of the compatibility layer is obtained, and the first coordinate is converted into the second coordinate in the client area coordinate system of the target input window; The second coordinate is converted to a third coordinate in the X11 top-level window coordinate system, and the input position attribute of the input context corresponding to the target input window is updated to the third coordinate.

2. The method according to claim 1, characterized in that, The step of obtaining the first coordinates of the current input position in the screen coordinate system of the compatibility layer and converting the first coordinates into the second coordinates in the client area coordinate system of the target input window includes: Obtain the current GUI thread information of the target Windows application, and determine whether the target handle in the current GUI thread information is valid; the target handle points to the window with the active caret. If the target handle is valid, then obtain the first coordinate of the active caret and convert the first coordinate of the active caret into the second coordinate; If the target handle is invalid, obtain the first coordinate of the current mouse and convert the first coordinate of the current mouse into the second coordinate.

3. The method according to claim 1, characterized in that, The step of updating the input position attribute of the input context corresponding to the target input window to the third coordinate includes: Set the value of the preset global variable to the third coordinate, and set the value of the preset global identifier to the target value; The input context corresponding to the target input window is obtained by calling the first interface provided by the compatibility layer. Write the value of the preset global variable into the input position attribute of the input context corresponding to the target input window.

4. The method according to claim 1, characterized in that, The method further includes: When creating the input context corresponding to the target input window, read the value of the preset global identifier; If the value of the preset global identifier is the target value, then the value of the preset global variable is read as the initial coordinate; the preset global variable is used to record the value of the input position attribute of the last update; If the value of the preset global identifier is not the target value, then the third coordinate of the active caret is calculated as the initial coordinate; The input position attribute of the input context corresponding to the target input window is initialized to the initial coordinates.

5. The method according to claim 1, characterized in that, The method further includes: The input method service is notified that the input position attribute of the target input window has been updated, so that the input method service displays the input method candidate box according to the position indicated by the updated input position attribute.

6. The method according to claim 1, characterized in that, The method further includes: Receive the first encoded string submitted by the input method service for the candidate words selected by the user; Convert the first encoded string into a second encoded string that conforms to the Windows system; The second encoded string is submitted to the message queue corresponding to the target window so that the target window receives and displays it in sequence.

7. The method according to claim 6, characterized in that, Submitting the second encoded string to the message queue corresponding to the target window includes: Determine whether the target input window is the focused window; If the target input window is the focused window, the second encoded string is submitted to the message queue corresponding to the target input window by calling the second interface provided by the compatibility layer; If the target input window is not the focus window, the focus window is determined by calling the third interface provided by the compatibility layer, and the second encoded string is submitted to the message queue corresponding to the focus window by calling the second interface.

8. The method according to claim 6, characterized in that, Submitting the second encoded string to the message queue corresponding to the target window includes: If the target Windows application does not support input method messages, the second encoded string is submitted character by character to the message queue corresponding to the target window.

9. The method according to claim 6, characterized in that, Submitting the second encoded string to the message queue corresponding to the target window includes: The second encoded string is split into characters and submitted sequentially. The characters to be submitted on different paths are compared with the characters in the target cache. If they are the same and the interval is less than a preset time, the characters to be submitted are ignored. The target cache is used to cache the characters that were last successfully submitted.

10. An input processing device, characterized in that, A compatibility layer applied to a Linux system, the device comprising: The message monitoring module is used to monitor target messages in real time during the text input operation of the target input window of the target Windows application running in the compatibility layer; the target messages include any of the following: mouse movement messages, mouse click messages, and window gaining input focus messages; The coordinate transformation module is used to, when the target message is detected, obtain the first coordinate of the current input position in the screen coordinate system of the compatibility layer, and convert the first coordinate into the second coordinate in the client area coordinate system of the target input window; and convert the second coordinate into the third coordinate in the X11 top-level window coordinate system; The attribute update module is used to update the input position attribute of the input context corresponding to the target input window to the third coordinate.

11. An electronic device, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the steps of the input processing method as described in any one of claims 1 to 9.

12. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the input processing method as described in any one of claims 1 to 9.

Images