Binding method and device for desktop plug-in instance, terminal and storage medium

Abstract

The application discloses a kind of binding methods, device, terminal and storage medium for desktop plug-in instance, belong to desktop plug-in field, comprising: after Widget instantiation is completed, create capability context data structure body and inject QML context;Plug-in side and host side register capability object respectively, generate dual-source feature provider list and set priority.When QML component is triggered, according to context backtracking to the Widget instance of belonging and obtaining feature key value, read dual-source list;Utilize preset rule to generate sorting object list, find corresponding QObject capability object and bind with QML component.Running time supports querying the highest priority capability object through uniform interface, and realizes the linkage refresh of state change and interface through Qt signal slot mechanism.Overcome the technical problem of matching confusion of interface and bottom logic.

Description

Technical Field

[0001] This invention relates to the field of desktop plugin technology, and in particular to a binding method, apparatus, terminal, and storage medium for desktop plugin instances. Background Technology

[0002] To meet the need for flexible expansion, desktop client applications generally adopt a "host application + plugin" architecture. Especially in the development of desktop applications based on the Qt / QML framework, plugins are usually discovered, loaded, and rendered by the host application in the form of "plugin package + dynamic library + UI entry point".

[0003] However, as application scenarios become more complex, the same plugin often needs to run in different host environments such as the taskbar, sidebar, and desktop container. The plugin interface not only needs to display its own static content, but also needs to frequently access business state objects (such as search status, notification status, task status, etc.) held by the host side.

[0004] In the process of developing this invention, the inventors discovered the following technical problems: In the prior art, in order to access the state objects on the host side, plugins are usually required to directly link to the specific business classes or SDKs of the host application during development. Although this approach provides clear type information, it creates a strong compile-time dependency on the host for the plugin. Once the host application is upgraded, modules are split, or the object model is adjusted, the plugin must be modified and recompiled synchronously, making it difficult to seamlessly reuse the same plugin in different host environments. Furthermore, when multiple instances of the same plugin exist, it is difficult to ensure a one-to-one correspondence between business capability objects and specific Widget instances, easily leading to mutual contamination between instances. This can easily cause mismatches between the interface and the underlying logic. Summary of the Invention

[0005] This invention provides a binding method, device, terminal, and storage medium for desktop plugin instances to solve the technical problem of mismatch between the interface and the underlying logic in the prior art.

[0006] In a first aspect, embodiments of the present invention provide a binding method for desktop plugin instances, comprising: When a component in the QML interface is triggered, find the trigger instance of that component; The trigger instance is traced back to its corresponding Widget instance based on its QML engine context or properties. Obtain the feature key value of the trigger instance; Read the list of plugin-side feature providers and the list of host-side feature providers for the Widget instance; The objects in the plugin-side feature provider list and the host-side feature provider list are traversed using preset traversal rules to generate a sorted object list. The host-side feature provider list includes a collection of capability providers registered to a specified Widget instance by the application that loads the plugin at runtime. The plugin-side feature provider list includes providers that have external capability declarations and QObject capability objects. The corresponding QObject capability object is searched in the sorted object list using the feature key value. When the corresponding QObject capability object is found, the QObject capability object is bound to the component interface property, event handler or state synchronization logic in the QML interface.

[0007] Secondly, embodiments of the present invention also provide a binding device for desktop plugin instances, comprising: The lookup module is used to find the trigger instance of a component when it is triggered in the QML interface; The backtracking module is used to backtrack to the corresponding Widget instance based on the QML engine context or attributes of the triggering instance; The acquisition module is used to acquire the feature key value of the trigger instance; The reading module is used to read the list of plugin-side feature providers and the list of host-side feature providers of the Widget instance; The traversal module is used to traverse the objects in the plugin-side feature provider list and the host-side feature provider list using preset traversal rules, and generate a sorted object list. The host-side feature provider list includes: a collection of capability providers registered to a specified Widget instance by the application that loads the plugin at runtime; the plugin-side feature provider list includes: providers that have external capability declarations and QObject capability objects. The binding module is used to search for the corresponding QObject capability object in the sorted object list using the feature key value. When the corresponding QObject capability object is found, the QObject capability object is bound to the component interface property, event handler or state synchronization logic in the QML interface.

[0008] Thirdly, embodiments of the present invention also provide a terminal, including: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the binding method for desktop plugin instances as described in any of the above embodiments.

[0009] Fourthly, embodiments of the present invention also provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the binding method for desktop plugin instances as provided in the above embodiments.

[0010] The binding method, apparatus, terminal, and storage medium for desktop plugin instances provided in this invention involve: when a component in a QML interface is triggered, finding the triggering instance of the component; traversing back to the corresponding Widget instance based on the QML engine context or attributes of the triggering instance; obtaining the feature key value of the triggering instance; reading the plugin-side feature provider list and the host-side feature provider list of the Widget instance; traversing the objects in the plugin-side feature provider list and the host-side feature provider list using preset traversal rules to generate a sorted object list. The host-side feature provider list includes a collection of capability providers registered to a specified Widget instance by the application loading the plugin at runtime; the plugin-side feature provider list includes providers with external capability declarations and QObject capability objects; using the feature key value to find the corresponding QObject capability object in the sorted object list; and when the corresponding QObject capability object is found, binding the QObject capability object to the component interface attributes, event handlers, or state synchronization logic in the QML interface. Binding can be performed using a single Widget instance as the anchor point. When multiple instances of the same plugin run concurrently on different hosts, each QML component, upon triggering, can accurately trace back to its own Widget instance, ensuring a strict one-to-one correspondence between business capability objects and instances. This completely avoids naming conflicts and cross-contamination issues caused by global exposure. Complex underlying object injection paths are abstracted into unified string key-value pairs. QML front-end components do not need to be aware of the specific business class type, object source, or compile-time dependencies of the host; they can dynamically obtain the required capability objects and bind attributes, events, or states using unified feature key-value pairs. This significantly lowers the development threshold for plugins, enabling truly seamless cross-host reuse. Plugins can carry default capabilities to ensure independent operation, and hosts can dynamically register capabilities with specified Widget instances at runtime to adapt to specific scenarios. Developers do not need to write complex adaptation code. By aggregating and sorting the dual-source list using preset traversal rules, a deterministic sorted object list is generated. The system can output unique capability objects according to fixed priority logic, avoiding access ambiguity and runtime chaos, significantly improving the reliability and stability of capability scheduling under the plugin architecture. This overcomes the technical problem of mismatch between the interface and underlying logic. Attached Figure Description

[0011] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart illustrating the binding method for desktop plugin instances provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart illustrating the binding method for desktop plugin instances provided in Embodiment 2 of the present invention; Figure 3 This is a schematic diagram of the binding device for desktop plugin instances provided in Embodiment 3 of the present invention; Figure 4 This is a schematic diagram of the terminal provided in Embodiment 4 of the present invention. Detailed Implementation

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

[0013] Example 1 Figure 1 This is a flowchart of a binding method for desktop plugin instances provided in Embodiment 1 of the present invention. This method can be executed by a binding device for desktop plugin instances, and specifically includes the following steps: Step 110: When a component in the QML interface is triggered, find the trigger instance of the component.

[0014] In this embodiment, the method can be based on a desktop plugin system of the Qt / QML framework.

[0015] For example, the triggering of a component in the QML interface may include: triggering a component in the QML interface when it is triggered by a user interaction; triggering a component in the QML interface when it finishes loading and initializing; triggering a component in the QML interface when its attributes change and are bound; and triggering a component in the QML interface when its backend C++ object emits a signal.

[0016] A QML interface can be composed of various components. These components can refer broadly to various UI elements in the QML object tree (such as buttons, list items, text boxes, etc.) or QML objects that perform specific business logic. When a component in the QML interface needs to access a business state, action, or service proxy, it triggers a call to the unified query interface. Upon triggering, the current QML object that initiated the call is first located and identified as the triggering instance of the component.

[0017] Step 120: Backtrack to the Widget instance based on the QML engine context or properties of the triggering instance.

[0018] In complex QML object trees, due to the potentially deep nesting of front-end UI components, the triggering instance initiating the query often doesn't directly perceive the macro-level business module it belongs to. Therefore, a backtracking mechanism is needed to establish an accurate association between the underlying QML triggering instance and the higher-level plugin runtime entity.

[0019] The Widget instance can be a single running entity of a plugin loaded within the plugin framework. It is bound to a unique instance ID, its own container (such as the taskbar or sidebar), and the context data for this runtime. In this embodiment, although all plugin instances share the same QML engine, each Widget instance has its own independent QML context.

[0020] For example, the current Widget instance can be automatically located in the QML object tree via attached property bridging. If the triggering instance itself or its direct parent in the QML component has a specific attached property, the capability bridging layer, upon receiving a reference to the triggering instance, can directly read the value bound to that attached property, reverse-resolve, and directly obtain the Widget instance to which it belongs. Alternatively, if the current triggering instance is in a deeper hierarchy and does not directly have the aforementioned attached property attached, the QML engine context in which the triggering instance resides is obtained. Since each Widget instance is assigned an independent context upon instantiation, and these contexts form a parent-child chain relationship within the engine, the query proceeds level by level along the parent chain of the triggering instance's context until the root context containing runtime association information for the Widget instance, such as the instance ID or capability context data structure, is located, thus ultimately determining the Widget instance to which the triggering instance belongs. Using this method, a one-to-one correspondence between business capability objects and specific Widget instances can be effectively guaranteed.

[0021] Step 130: Obtain the feature key value of the triggering instance.

[0022] In this embodiment, the feature key value can be a string key used to uniquely identify a capability object. The feature key value serves as a unified addressing contract between the QML frontend and the underlying backend capability objects.

[0023] When a trigger instance needs to access a certain state, action, or service proxy, it initiates a call to the unified interface exposed by the capability bridging layer. The feature key value is passed to the capability bridging layer as a necessary input parameter for the interface call. Upon receiving the call request, the layer parses and extracts the feature key value string, which serves as the core index for subsequent matching in the provider list. Using the obtained feature key value, deep decoupling between the front-end UI and back-end logic, as well as lightweight querying, can be achieved.

[0024] Step 140: Read the list of plugin-side feature providers and the list of host-side feature providers for the Widget instance.

[0025] For example, the host-side feature provider list includes a set of capability providers registered to a specified Widget instance by the application loading the plugin at runtime; the plugin-side feature provider list includes providers with external capability declarations and QObject capability objects. For example, these providers typically originate from within the plugin package. During the plugin loading phase, when the Widget instance loads the dynamic library from the plugin package on demand, and the dynamic library implements the unified plugin interface, the dynamic library plugin instance can return a set of plugin-side feature provider objects to the framework. The plugin-side feature provider list represents the default capability set carried by the plugin itself, ensuring that the plugin still possesses basic independent operating capabilities when it is removed from specific host enhancements.

[0026] The host application can dynamically add or override host-side provider objects to the Widget instance at runtime, based on the current business scenario and its own state (such as system-level search state, notification center state, etc.). Utilizing the plugin-side feature provider list and the host-side feature provider list allows the host and plugins to jointly provide capabilities to QML in a decoupled manner. Plugins carry default capabilities, while the host dynamically supplements or overrides them according to the scenario, eliminating the need for developers to write complex adaptation code for each host.

[0027] During the initialization of a Widget instance and its placement within its corresponding container, the internal storage structure of the Widget instance receives and maintains references to provider objects from both sides. Once the current Widget instance is located, its runtime context data is directly accessed to read and retrieve the list of plugin-side feature providers and the list of host-side feature providers.

[0028] Step 150: Use preset traversal rules to traverse the objects in the plugin-side feature provider list and the host-side feature provider list to generate a sorted object list.

[0029] For example, the step of traversing the objects in the plugin-side feature provider list and the host-side feature provider list using preset traversal rules may include: when there are objects with the same feature key value in the plugin-side feature provider list and the host-side feature provider list, selecting the object in the plugin-side feature provider list; when there are objects with the same feature key value in the same provider list, selecting the object that was registered later.

[0030] The plugin-side feature provider list is obtained, and the provider objects within it are traversed in reverse order of their return. Simultaneously, the host-side feature provider list is obtained, and the provider objects within it are traversed in reverse order of their registration. The processed plugin-side list is concatenated before the processed host-side list to form a candidate sequence. Next, the bridging layer performs a capability scan on this candidate sequence. For multiple providers declaring support for the same feature key value, priority logic is used for deduplication; that is, only the provider ranked first in the candidate sequence is retained in the sorted object list, and duplicate declarations following it are removed.

[0031] Using the above method, a sorted list of objects is generated, aggregating the effective capabilities of both the plugin and host sides, with each feature key value being unique. Furthermore, this sorted list of objects and the extracted list of usable feature keys can be cached for direct reuse in subsequent queries, reducing the computational overhead of repeated traversal.

[0032] When both the host and plugin provide capability objects with the same name, the system can automatically adjudicate according to a fixed priority logic and generate a unified sorted list, eliminating the need for developers to manually write hard-coded judgment logic. This not only solves the problem of coordinating capabilities from two sources but also ensures the stability and reliability of capability acquisition, enabling the interface to deterministically obtain capability objects that conform to the current priority strategy.

[0033] Step 160: Use the feature key value to search for the corresponding QObject capability object in the sorted object list. When the corresponding QObject capability object is found, bind the QObject capability object to the component interface property, event handler or state synchronization logic in the QML interface.

[0034] Using the feature key values ​​obtained in the preceding steps, perform a match search one by one in the generated list of sorted objects. Optionally, traverse the feature provider objects in the sorted object list in order. For each provider, first call its capability judgment interface to inquire whether it supports the feature key; if a positive response is received, further call its object retrieval interface (e.g., feature(key)) to request the specific QObject capability object.

[0035] If, during the iteration, a provider confirms support for the feature key and successfully returns a non-empty QObject capability object, iteration over subsequent providers can be stopped, and the matched QObject capability object will be used as the resolution result. If, after iterating through the entire sorted object list, none of the providers can return a valid object, an error message is logged and an empty value is returned to the QML side to trigger subsequent fallback display or disable interaction logic.

[0036] After locating the corresponding QObject capability object and returning it to the QML trigger instance that initiated the request, the QML component utilizes Qt / QML's meta-object system and dynamic binding mechanism to deeply bind the QObject capability object to elements in the QML interface. Optionally, the properties exposed by the QObject capability object can be directly bound to the visual properties of the QML component. When the capability object's properties change, the QML engine automatically triggers a visual refresh of the interface. Alternatively, the interactive events of the QML component (such as button clicks and slider drags) can be associated with the callable methods exposed by the QObject capability object, allowing front-end interactions to directly call back-end business logic. Or, by capturing Qt signals emitted by the QObject capability object, corresponding state synchronization JavaScript logic can be executed on the QML side, achieving real-time linkage between the underlying business state and the front-end interface performance.

[0037] It should be noted that the object returned by the feature provider is a QObject instance in the Qt framework. However, the object can also be a wrapper around a remote object, a DBus object, a script object, or a lightweight RPC proxy object. As long as the wrapped object can be recognized by the QML side through the meta-object system or context property mechanism, the binding of the above-mentioned UI properties, events, or states can also be achieved.

[0038] This embodiment finds the trigger instance of a component when it is triggered in a QML interface; backtracks to the corresponding Widget instance based on the QML engine context or attributes of the trigger instance; obtains the feature key value of the trigger instance; reads the plugin-side feature provider list and the host-side feature provider list of the Widget instance; iterates through the objects in the plugin-side feature provider list and the host-side feature provider list using preset traversal rules to generate a sorted object list. The host-side feature provider list includes a collection of capability providers registered to a specified Widget instance by the application loading the plugin at runtime; the plugin-side feature provider list includes providers with external capability declarations and QObject capability objects; the corresponding QObject capability object is found in the sorted object list using the feature key value; and when a corresponding QObject capability object is found, it is bound to the component interface attributes, event handlers, or state synchronization logic in the QML interface. Binding can be done using a single Widget instance as the anchor point. When multiple instances of the same plugin run concurrently on different hosts, each QML component, upon triggering, can accurately trace back to its own Widget instance, ensuring a strict one-to-one correspondence between business capability objects and instances. This completely avoids naming conflicts and cross-contamination issues caused by global exposure. Complex underlying object injection paths are abstracted into unified string key-value pairs. QML front-end components do not need to be aware of the specific business class type, object source, or compile-time dependencies of the host; they can dynamically obtain the required capability objects and bind attributes, events, or states using unified feature key-value pairs. This significantly lowers the development threshold for plugins, enabling truly seamless cross-host reuse. Plugins can carry default capabilities to ensure independent operation, and hosts can dynamically register capabilities with specified Widget instances at runtime to adapt to specific scenarios. Developers do not need to write complex adaptation code. By aggregating and sorting the dual-source list using preset traversal rules, a deterministic sorted object list is generated. The system can output unique capability objects according to fixed priority logic, avoiding access ambiguity and runtime chaos, significantly improving the reliability and stability of capability scheduling under the plugin architecture. This overcomes the technical problem of mismatch between the interface and underlying logic.

[0039] Example 2 Figure 2This is a flowchart illustrating the binding method for desktop plugin instances provided in Embodiment 2 of the present invention. This embodiment is an optimization based on the above embodiment, and the method may further include the following steps: After the Widget is instantiated, a capability context data structure corresponding to the Widget instance is created; the capability context data structure is written into a global mapping table, and the identifier of the Widget instance is used as the key value of the capability context data structure; using the context injection mechanism of the QML engine, the capability context data structure is injected into the QML context of the Widget instance to form a context attribute. Further, the following steps may be added: On the plugin side, during plugin initialization, the capability objects provided by the plugin side are registered in the capability context data structure; on the host side, the host-side capability objects are registered in the capability context data structure, and priority options are set to allow for setting the priority of the host-side capability objects in different scenarios; a plugin-side feature provider list is generated using the registered plugin-side capability objects, and a host-side feature provider list is generated using the registered host-side host-side capability objects.

[0040] See Figure 2 The binding method for desktop plugin instances includes: Step 210: After the Widget is instantiated, create the capability context data structure corresponding to the Widget instance, write the capability context data structure into the global mapping table, and use the identifier of the Widget instance as the key value of the capability context data structure.

[0041] In this embodiment, the completion of Widget instantiation can refer to the lifecycle node where the plugin framework loads the plugin dynamic library, allocates memory resources, and instantiates the specific plugin runtime entity. At this point, the Widget instance has been assigned a unique instance identifier (such as a UUID or an auto-incrementing instance ID) and is ready to begin building its dedicated runtime environment. The capability context data structure can be a data container specifically allocated for a single Widget instance, used to aggregate and manage all capability provider objects and priority configurations for that instance. For example, it can be a C++ structure or class object.

[0042] When the lifecycle of a Widget instance is detected to have entered the instantiation completion phase, the initialization logic is triggered. A new capability context data structure is dynamically created in memory. This structure is either empty or contains only default configurations, and is ready to receive subsequent capability registrations from the plugin side and the host side.

[0043] Get the identifier (Instance ID) of the current Widget instance, use the identifier as the key, and write the pointer or reference of the newly created capability context data structure as the value to the global mapping table.

[0044] Using the above method, each Widget instance can have its own independent capability container. Even if multiple instances of the same plugin run in parallel within the same host application, the capability contexts will not interfere with each other, completely avoiding state pollution in the traditional global singleton pattern. Furthermore, by utilizing a global mapping table, the host side can inject capabilities into specific instances at runtime, and the QML side can backtrack to find the capabilities of specific instances when triggered.

[0045] Step 220: Using the context injection mechanism of the QML engine, the capability context data structure is injected into the QML context of the Widget instance to form context attributes.

[0046] For example, the context injection mechanism of the QML engine can be a cross-language data communication mechanism provided by the Qt / QML framework, which allows objects created on the C++ side, especially QObject-derived classes, to be registered in the context environment of the QML engine. Once the registration is complete, the QML side code can directly reference the corresponding C++ object as if it were a global variable, and interact with its properties, methods, and signals.

[0047] The QML context of a Widget instance can refer to the runtime environment context allocated by the QML engine when loading the UI file of a specific Widget instance. Furthermore, to achieve multi-instance isolation, the context can be a sub-context of the engine's root context.

[0048] The context property can be an object bound to a specific QQmlContext through the above injection mechanism, and is represented in QML code as a global property with a conventional name.

[0049] When a Widget instance is preparing to load its front-end QML interface file, it first obtains or creates a QML context object specific to that Widget instance. Then, it obtains a pointer to the capability context data structure corresponding to the Widget instance created in the preceding steps.

[0050] By leveraging the QML engine's context injection mechanism, a context setting interface, such as `QQmlContext::setContextProperty()`, is called to inject the capability context data structure into the QML context of the Widget instance with a pre-defined property name. This makes the capability context data structure a context property specific to the corresponding Widget instance. After injection, the QML component is instantiated and loaded within this QML context environment that already contains the context property. Using this method, all QML components within the Widget instance can directly access the underlying capability context data structure through the agreed-upon property name. This approach allows QML components to directly access the capability context of their instance without complex parameter passing. Furthermore, because the injection occurs within the Widget instance's specific sub-context, based on the inheritance and shading characteristics of the QML engine's context parent chain, the QML code of different Widget instances can only access their own injected context properties, fundamentally preventing out-of-bounds access and data obfuscation between different plugin instances.

[0051] Step 230: On the plugin side, during plugin initialization, the capability objects provided by the plugin side are registered in the capability context data structure. On the host side, the host-side capability objects are registered in the capability context data structure, and priority options are set so that the priority of the host-side capability objects can be set accordingly in different scenarios.

[0052] During Widget instantiation, the framework loads the plugin's dynamic library and creates a plugin instance. During the plugin instance initialization phase, the plugin implements a predefined unified interface and returns its internally encapsulated capability objects, i.e., feature providers, to the framework. Upon receiving these objects, the framework registers them and writes them into the capability context data structure corresponding to the current Widget instance, forming the instance's basic capability set.

[0053] During the process of the host application loading and running the Widget instance, the host application, based on the current business scenario (e.g., determining whether it is running in the notification center or the search panel), obtains the capability context data structure corresponding to the Widget instance through the aforementioned global mapping table. The host application registers the prepared host-side capability objects into this data structure. The host application sets priority options for the registered host-side capability objects. These priority options allow the host to flexibly adjust its strategy in different scenarios. For example, in scenario A, the host capability priority can be set lower than the plugin's default capability to achieve a supplementary effect, or in scenario B, the host capability priority can be set higher than the plugin's default capability to achieve an overriding effect.

[0054] Using the above method, plugin developers only need to register the default capability once on the plugin side, without having to write complex specific adaptation code for each different host application; the host application can then dynamically inject proprietary capabilities according to its own scenario. Furthermore, by introducing priority options, the host application can dynamically determine the provider of capabilities at runtime based on different scenarios, enabling the same plugin code to exhibit correct behavior consistent with the host's business logic across different hosts, greatly improving the system's scalability and scenario adaptability.

[0055] Step 240: Generate a list of plugin-side feature providers using the capability objects provided by the registered plugin side, and generate a list of host-side feature providers using the host-side capability objects registered by the registered host side.

[0056] In this embodiment, the feature provider list can refer to a linear collection maintained within the capability context data structure for storing feature provider objects. The list can be explicitly divided into two branches: a plugin-side feature provider list and a host-side feature provider list, both originating from independent sources. Each branch not only records the capability object itself but also implicitly or explicitly records the object's registration sequence to meet subsequent requirements for deduplication or sorting based on shared origins.

[0057] On the plugin side, after the framework receives the capability objects returned by the plugin instance during initialization and completes the registration, the capability context data structure extracts these objects and appends them to the internal plugin-side array or linked list in the order they are received, thereby generating a list of plugin-side feature providers.

[0058] On the host side, when the host application calls the registration interface to write the host-side capability object and priority options into the structure, the structure also appends the object to the internal host-side array or linked list in the order of registration time, thereby generating a list of host-side feature providers. Throughout the entire runtime of the Widget instance, if dynamic capabilities are added or removed on the host side, such as a business scenario change causing a host capability to be uninstalled, the list of host-side feature providers will be dynamically updated to maintain consistency with the runtime state.

[0059] Step 250: When a component in the QML interface is triggered, find the trigger instance of the component, trace back to the Widget instance to which it belongs based on the QML engine context or attributes of the trigger instance, and obtain the feature key value of the trigger instance.

[0060] Step 260: Read the plugin-side feature provider list and the host-side feature provider list of the Widget instance, and use preset traversal rules to traverse the objects in the plugin-side feature provider list and the host-side feature provider list to generate a sorted object list.

[0061] Step 270: Use the feature key value to search for the corresponding QObject capability object in the sorted object list. When the corresponding QObject capability object is found, bind the QObject capability object to the component interface property, event handler or state synchronization logic in the QML interface.

[0062] This embodiment adds the following steps: After the Widget is instantiated, a capability context data structure corresponding to the Widget instance is created; the capability context data structure is written into a global mapping table, and the identifier of the Widget instance is used as the key-value pair of the capability context data structure; using the context injection mechanism of the QML engine, the capability context data structure is injected into the QML context of the Widget instance to form a context attribute. Further, the following steps can be added: On the plugin side, during plugin initialization, the capability objects provided by the plugin side are registered in the capability context data structure; on the host side, the host-side capability objects are registered in the capability context data structure, and priority options are set to allow for setting the priority of the host-side capability objects in different scenarios; a list of plugin-side feature providers is generated using the registered plugin-side capability objects, and a list of host-side feature providers is generated using the registered host-side host-side capability objects. This avoids the data pollution and state confusion problems caused by multiple Widget instances sharing the same state in the traditional global singleton mode. It improves code reusability and system scalability, and ensures that the front end obtains only the single valid capability object that conforms to the current host strategy in any complex business scenario. This not only solves the capability conflict problem, but also gives the host application a high degree of scenario control.

[0063] In a preferred embodiment of this example, the method may further include the following steps: when a QML business logic event triggers a requirement for host capabilities, a unified lightweight capability query interface is invoked to obtain the capability context data structure corresponding to the Widget instance using the Widget instance identifier; the highest priority capability object is then obtained using the corresponding capability context data structure. The unified lightweight capability query interface may refer to a single query entry function exposed externally by the framework layer (including the QML frontend and other host modules). Internally, the interface encapsulates complex logic involving global mapping table lookup and dual-source list traversal, eliminating the need for the caller to be aware of the underlying data structure's organization. In the QML business logic, when a requirement event is triggered, the QML side obtains the identifier of the currently belonging Widget instance. The QML side or its associated C++ proxy object invokes the unified lightweight capability query interface, passing the Widget instance identifier and the required target feature key as input parameters. Upon receiving the interface call, the framework layer uses the passed Widget instance identifier as the search key to perform a hash lookup in the global mapping table residing in memory, thereby quickly obtaining the capability context data structure corresponding to the Widget instance. The interface internally calls the capability resolution method provided by the structure, reads the plugin-side feature provider list and the host-side feature provider list maintained within the structure, and iterates and compares them according to the system's preset cross-source and same-source priority rules. Finally, it determines and returns the capability object with the highest priority that supports the specified feature key. Using this method, QML front-end developers do not need to write complex context backtracking judgments and dual-source list sorting logic in their business code. They only need to call a lightweight unified interface and pass in the instance ID to transparently obtain the correct capability object that conforms to the current system's priority strategy, improving development efficiency. By forcing all capability requests to go through the priority determination logic of the capability context data structure through the interface, the possibility of bypassing the framework and directly hardcoding calls to specific providers is eliminated, ensuring that the capability object obtained in any scenario is the valid object with the highest global priority.

[0064] In another preferred embodiment of this example, the method may further include the following step: when the state of a capability object changes, a state change notification is issued. The capability context data structure receives the notification and triggers a state change signal through the Qt signal-slot mechanism, so that QML performs a synchronized interface refresh based on the state change signal. During the runtime state refresh phase, the above method is used to achieve efficient and decoupled driving of the front-end QML interface update through the intermediate layer data structure for changes in underlying business data. The state change notification may be a data change event issued by the capability object when its internal business state (such as on / off state, progress value, availability flag, etc.) changes during runtime. Correspondingly, the capability context data structure not only serves as a storage container for capability objects but also undertakes the responsibility of signal aggregation and forwarding. The QML front-end does not directly listen to the signals of each dynamically acquired capability object but uniformly listens to the signals issued by the capability context data structure. For example, during the runtime of a Widget instance, when the internal state of a registered and providing service QObject capability object changes, the capability object actively issues a state change notification based on the Qt meta-object system. When a capability object is registered to the capability context data structure, its state change notification is already connected to the receiving slot function within the structure, allowing the capability context data structure to receive the notification in real time. Upon receiving the notification, the capability context data structure performs internal data aggregation or validation based on the type of state change or associated feature key values. Then, through the Qt signal and slot mechanism, it triggers its predefined state change signal to be broadcast externally. On the QML side, since the front-end component has already obtained a reference to the capability context data structure through context properties during initialization and pre-bound the handling mechanism for the state change signal, when the structure emits a state change signal, the QML engine immediately captures the signal and executes the corresponding JavaScript processing logic, thereby achieving a synchronized refresh of the interface. Using this method, the QML side only needs to bind the structure's signal once during initialization to receive state updates from all underlying capability objects, completely simplifying the front-end signal management logic. The QML side makes its own decisions based on the received uniformly formatted signals, mapping state changes to specific UI elements, improving system maintainability and code clarity.

[0065] Example 3 Figure 3 This is a schematic diagram of the binding device for desktop plugin instances provided in Embodiment 3 of the present invention. See also... Figure 3 The binding device for desktop plugin instances includes: The lookup module 310 is used to look up the trigger instance of a component when the component in the QML interface is triggered. The backtracking module 320 is used to backtrack to the Widget instance to which the triggering instance belongs based on the QML engine context or attributes of the triggering instance; The acquisition module 330 is used to acquire the feature key value of the trigger instance; The reading module 340 is used to read the list of plugin-side feature providers and the list of host-side feature providers of the Widget instance; The traversal module 350 is used to traverse the objects in the plugin-side feature provider list and the host-side feature provider list using preset traversal rules to generate a sorted object list. The host-side feature provider list includes a collection of capability providers registered to a specified Widget instance by the application that loads the plugin at runtime. The plugin-side feature provider list includes providers that have external capability declarations and QObject capability objects. The binding module 360 ​​is used to search for the corresponding QObject capability object in the sorted object list using the feature key value. When the corresponding QObject capability object is found, the QObject capability object is bound to the component interface property, event handler or state synchronization logic in the QML interface.

[0066] The binding device for desktop plugin instances provided in this embodiment searches for the triggering instance of a component when it is triggered in a QML interface; backtracks to the corresponding Widget instance based on the QML engine context or attributes of the triggering instance; obtains the feature key value of the triggering instance; reads the plugin-side feature provider list and the host-side feature provider list of the Widget instance; iterates through the objects in the plugin-side feature provider list and the host-side feature provider list using preset traversal rules to generate a sorted object list. The host-side feature provider list includes a collection of capability providers registered to a specified Widget instance by the application loading the plugin at runtime; the plugin-side feature provider list includes providers with external capability declarations and QObject capability objects; the device searches for the corresponding QObject capability object in the sorted object list using the feature key value; and when the corresponding QObject capability object is found, it binds the QObject capability object to the component interface attributes, event handlers, or state synchronization logic in the QML interface. Binding can be performed using a single Widget instance as the anchor point. When multiple instances of the same plugin run concurrently on different hosts, each QML component, upon triggering, can accurately trace back to its own Widget instance, ensuring a strict one-to-one correspondence between business capability objects and instances. This completely avoids naming conflicts and cross-contamination issues caused by global exposure. Complex underlying object injection paths are abstracted into unified string key-value pairs. QML front-end components do not need to be aware of the specific business class type, object source, or compile-time dependencies of the host; they can dynamically obtain the required capability objects and bind attributes, events, or states using unified feature key-value pairs. This significantly lowers the development threshold for plugins, enabling truly seamless cross-host reuse. Plugins can carry default capabilities to ensure independent operation, and hosts can dynamically register capabilities with specified Widget instances at runtime to adapt to specific scenarios. Developers do not need to write complex adaptation code. By aggregating and sorting the dual-source list using preset traversal rules, a deterministic sorted object list is generated. The system can output unique capability objects according to fixed priority logic, avoiding access ambiguity and runtime chaos, significantly improving the reliability and stability of capability scheduling under the plugin architecture. This overcomes the technical problem of mismatch between the interface and underlying logic.

[0067] Based on the above embodiments, the traversal module includes: The first selection unit is used to select an object from the plugin-side feature provider list when there are objects with the same feature key value in the plugin-side feature provider list and the host-side feature provider list. The second selection unit is used to select the object to be registered when there are objects with the same feature key value in the same provider list.

[0068] Based on the above embodiments, the search module includes: Trigger determination unit, used to limit the triggering of components in the QML interface by user interaction; When the component in the QML interface completes loading and initialization is triggered; When the property of a component in a QML interface changes, the binding is triggered; and When a signal is emitted by the backend C++ object of a component in the QML interface.

[0069] Based on the above embodiments, the device further includes: A module is created to create the capability context data structure corresponding to the Widget instance after the Widget is instantiated; The write module is used to write the capability context data structure to the global mapping table and use the identifier of the Widget instance as the key value of the capability context data structure. The injection module is used to inject the capability context data structure into the QML context of the Widget instance using the context injection mechanism of the QML engine, thereby forming context attributes.

[0070] Based on the above embodiments, the device further includes: The first registration module is used to register the capability objects provided by the plugin side in the capability context data structure during plugin initialization. The second registration module is used to register the host-side capability objects in the capability context data structure on the host side and set priority options so as to set the priority of the host-side capability objects in different scenarios. The list generation module is used to generate a list of plugin-side feature providers using the capability objects provided by the registered plugin side, and to generate a list of host-side feature providers using the host-side capability objects of the registered host side.

[0071] Based on the above embodiments, the device further includes: The interface call module is used to call the unified lightweight capability query interface when the QML business logic requires the host capability, and use the Widget instance identifier to obtain the capability context data structure corresponding to the Widget instance; The capability object acquisition module is used to acquire the highest priority capability object using the corresponding capability context data structure.

[0072] Based on the above embodiments, the device further includes: The notification sending module is used to send a status change notification when the status of a capability object changes. The capability context data structure receives the notification and triggers a status change signal through the Qt signal and slot mechanism, so that QML can refresh the interface in response to the status change signal.

[0073] The binding device for desktop plugin instances provided in this embodiment of the invention can execute the binding method for desktop plugin instances provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0074] Example 4 Figure 4 This is a schematic diagram of the structure of a terminal provided in Embodiment 4 of the present invention. Figure 4 A block diagram is shown of an exemplary terminal 12 suitable for implementing embodiments of the present invention. Figure 4 The terminal 12 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

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

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

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

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

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

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

[0081] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the binding method for desktop plugin instances provided in the embodiments of the present invention.

[0082] Example 5 Embodiment 5 of the present invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform a binding method for a desktop plugin instance as described in any of the above embodiments.

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

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

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

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

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

Claims

1. A binding method for desktop plugin instances, characterized in that, include: After the Widget is instantiated, the capability context data structure corresponding to the Widget instance is created; Write the capability context data structure into the global mapping table, and use the identifier of the Widget instance as the key of the capability context data structure; By utilizing the context injection mechanism of the QML engine, the capability context data structure is injected into the QML context of the Widget instance to form context properties; On the plugin side, during plugin initialization, the capability objects provided by the plugin side are registered in the capability context data structure; On the host side, the host-side capability objects are registered in the capability context data structure, and priority options are set so that the priority of the host-side capability objects can be set accordingly in different scenarios. Generate a list of plugin-side feature providers using the capability objects provided by the registered plugin side, and generate a list of host-side feature providers using the host-side capability objects registered by the host side; When a component in the QML interface is triggered, find the trigger instance of that component; The trigger instance is traced back to its corresponding Widget instance based on its QML engine context or properties. Obtain the feature key value of the trigger instance; Read the plugin-side feature provider list and the host-side feature provider list of the Widget instance, wherein the host-side feature provider list includes: a collection of capability providers registered to the specified Widget instance by the application that loads the plugin at runtime; the plugin-side feature provider list includes: providers that have the ability to make external declarations and QObject capability objects; The objects in the plugin-side feature provider list and the host-side feature provider list are traversed using preset traversal rules to generate a sorted object list. The corresponding QObject capability object is searched in the sorted object list using the feature key value. When the corresponding QObject capability object is found, the QObject capability object is bound to the component interface property, event handler or state synchronization logic in the QML interface. The step of traversing the objects in the plugin-side feature provider list and the host-side feature provider list using preset traversal rules includes: When objects have the same feature key value in both the plugin-side feature provider list and the host-side feature provider list, select the object from the plugin-side feature provider list; When objects with the same characteristic key value exist in the same provider list, the object that is registered later is selected.

2. The method according to claim 1, characterized in that, When a component in the QML interface is triggered, it includes: When a component in a QML interface is triggered by a user interaction; When the component in the QML interface completes loading and initialization is triggered; When the property of a component in a QML interface changes, the binding is triggered; and When a signal is emitted by the backend C++ object of a component in the QML interface.

3. The method according to claim 1, characterized in that, The method further includes: When the QML business logic requests the host capability, the unified lightweight capability query interface is called to obtain the capability context data structure corresponding to the Widget instance using the Widget instance identifier. The highest priority capability object is obtained using the corresponding capability context data structure.

4. The method according to claim 1, characterized in that, The method further includes: When the state of a capability object changes, a state change notification is issued. The capability context data structure receives the notification and triggers a state change signal through the Qt signal and slot mechanism, so that QML can refresh the interface in response to the state change signal.

5. A binding device for desktop plugin instances, characterized in that, include: A module is created to create the capability context data structure corresponding to the Widget instance after the Widget is instantiated; The write module is used to write the capability context data structure to the global mapping table and use the identifier of the Widget instance as the key value of the capability context data structure. The injection module is used to inject the capability context data structure into the QML context of the Widget instance using the context injection mechanism of the QML engine, thereby forming context attributes; The first registration module is used to register the capability objects provided by the plugin side in the capability context data structure during plugin initialization. The second registration module is used to register the host-side capability objects in the capability context data structure on the host side and set priority options so as to set the priority of the host-side capability objects in different scenarios. The list generation module is used to generate a list of plugin-side feature providers using the capability objects provided by the registered plugin side, and to generate a list of host-side feature providers using the host-side capability objects registered by the host side. The lookup module is used to find the trigger instance of a component when it is triggered in the QML interface; The backtracking module is used to backtrack to the corresponding Widget instance based on the QML engine context or attributes of the triggering instance; The acquisition module is used to acquire the feature key value of the trigger instance; The reading module is used to read the list of plugin-side feature providers and the list of host-side feature providers of the Widget instance; The traversal module is used to traverse the objects in the plugin-side feature provider list and the host-side feature provider list using preset traversal rules, and generate a sorted object list. The host-side feature provider list includes a collection of capability providers registered to a specified Widget instance by the application that loads the plugin at runtime. The plugin-side feature provider list includes providers that have external capability declarations and QObject capability objects. The binding module is used to search for the corresponding QObject capability object in the sorted object list using the feature key value. When the corresponding QObject capability object is found, the QObject capability object is bound to the component interface property, event handler or state synchronization logic in the QML interface. The traversal module includes: The first selection unit is used to select an object from the plugin-side feature provider list when there are objects with the same feature key value in the plugin-side feature provider list and the host-side feature provider list. The second selection unit is used to select the object to be registered when there are objects with the same feature key value in the same provider list.

6. A terminal, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the binding method for desktop plugin instances as described in any one of claims 1-4.

7. A storage medium containing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a computer processor, are used to perform the binding method for a desktop plugin instance as described in any one of claims 1-4.

Images