CN117032725A - Event processing method and device, electronic equipment and computer readable storage medium - Google Patents

Abstract

The disclosure relates to an event processing method and device, an electronic device and a computer readable storage medium. The method is applied to a first plug-in and comprises the following steps: responding to a processing request of a target event; determining an event release interface based on the event type of the target event, wherein parameters of the event release interface comprise an event name space and a theme name of the target event; determining a second plugin subscribed to the target event based on the event namespace and the topic name, wherein the second plugin is associated with the event namespace, the topic name, and the target event; and calling a second plug-in to process the target event.

Description

Event processing method and device, electronic equipment and computer readable storage medium

Technical Field

The present disclosure relates to the field of computers, and in particular, to an event processing method and apparatus, an electronic device, and a computer readable storage medium.

Background

The plug-in development architecture is a common application development architecture, and the logic of each service plug-in is relatively independent in service logic, but service interaction is usually carried out between plug-ins, and a mechanism for communication between plug-ins is needed for data interaction. If only communication between the plug-ins is to be achieved, it is certainly very simple, since in a c++ application each plug-in is a shared library, all shared libraries are loaded into a Process, the memory of which is shared. Therefore, the communication method commonly used at present is to directly exchange data through global variables, namely, realize communication among plugins through a code interface, but the coupling caused by the method is too strong, once one global variable is modified, all plugins need to be recompiled, for example, when a first plugin needs to call a second plugin to process an event, if the communication between two plugins is realized through the code interface, if the code interface of the second plugin is assumed to be ABC at first, the first plugin port is compiled by ABC, if ABC is modified later, for example, the ABD is modified, at the moment, the previously compiled first plugin still uses the code interface ABC, so that ABC cannot be found when the second plugin is called to process the corresponding event, namely, the second plugin cannot be called, so that the program is blocked on the calling operation, at the moment, the first plugin needs to be recompiled, and other plugins needing to call the second plugin also cannot be called to the second plugin, therefore, all other plugins adopting ABC need to be recompiled, so that the working load is larger.

Disclosure of Invention

The disclosure provides an event processing method and device, electronic equipment and a computer readable storage medium, so as to at least solve the problem that the related technology realizes the communication among plugins through a code interface, resulting in great workload.

According to a first aspect of an embodiment of the present disclosure, there is provided an event processing method, applied to a first plug-in, including: responding to a processing request of a target event; determining an event release interface based on the event type of the target event, wherein parameters of the event release interface comprise an event name space and a theme name of the target event; determining a second plugin subscribed to the target event based on the event namespace and the topic name, wherein the second plugin is associated with the event namespace, the topic name, and the target event; and calling a second plug-in to process the target event.

Optionally, the event types include a signal event, a slot event and a hook event, wherein in the case that the event type of the target event is the signal event, the first plugin registers the target event and issues the target event to the outside, the target event can be subscribed by a plurality of second plugins, and the plurality of second plugins process the target event; under the condition that the event type of the target event is a slot event, the second plug-in registers the target event and is the only subscriber of the target event, and the first plug-in externally publishes the target event; and under the condition that the event type of the target event is a hook event, the first plugin registers the target event and issues the target event outwards, and the target event can be subscribed by a plurality of second plugins, wherein one plugin in the plurality of second plugins processes the target event.

Optionally, in a case that the event type is a signal event, invoking a second plugin to process the target event, including: traversing the plurality of second plugins, and sequentially calling corresponding event processing functions in the second plugins to process the target event.

Optionally, the method further comprises: determining that the target event passes through an event filter, wherein the event filter is used for filtering out the event which does not meet the preset requirement.

Optionally, in a case that the event type is a slot event, invoking a second plugin to process the target event, including: and calling a corresponding event processing function in the unique second plug-in to process the target event.

Optionally, in a case that the event type is a hook event, invoking a second plugin to process the target event, including: and traversing the plurality of second plugins, sequentially calling corresponding event processing functions in the second plugins, and processing the target event, wherein if any event processing function return value in the traversal process indicates that the target event is processed, the calling of the corresponding event processing functions in the rest second plugins is stopped.

Optionally, the target event is registered by: determining an event type, a theme name and an event naming space of the target event; determining an event registration interface of a target event based on the event type, wherein parameters of the event registration interface comprise a theme name and an event naming space; determining a keyword and a unique identifier of a target event through an event registration interface, wherein the keyword comprises an event naming space and a theme name; the key and the unique identifier are stored in association.

Optionally, a second plug-in is invoked to process the target event, including: the method comprises the steps that a keyword is sent to a second plug-in, wherein the second plug-in determines a unique identifier of a target event based on an event name space and a theme name included by the keyword; determining a corresponding event processing function in the second plugin through the unique identifier; and processing the target event through the determined event processing function.

Optionally, the target event is subscribed to by the second plugin by: after the target event is successfully registered, determining an event processing function of the target event; determining an event subscription interface based on the event type of the target event; based on the determined event subscription interface, the event handling function is cached and associated with a unique identification of the target event.

According to a second aspect of the embodiments of the present disclosure, there is provided an event processing apparatus, including: a release interface determining unit configured to determine an event release interface based on an event type of the target event in response to a processing request of the target event, wherein parameters of the event release interface include an event namespace and a topic name of the target event; a second plugin determining unit configured to determine, in a case where the target event has been registered and subscribed, a second plugin subscribed to the target event based on the event namespace and the topic name, wherein the second plugin is associated with the event namespace, the topic name; and the processing unit is configured to call the second plug-in and process the target event.

Optionally, the event types include a signal event, a slot event and a hook event, wherein in the case that the event type of the target event is the signal event, the first plugin registers the target event and issues the target event to the outside, the target event can be subscribed by a plurality of second plugins, and the plurality of second plugins process the target event; under the condition that the event type of the target event is a slot event, the second plug-in registers the target event and is the only subscriber of the target event, and the first plug-in externally publishes the target event; and under the condition that the event type of the target event is a hook event, the first plugin registers the target event and issues the target event outwards, and the target event can be subscribed by a plurality of second plugins, wherein one plugin in the plurality of second plugins processes the target event.

Optionally, in the case that the event type is a signal event, the processing unit is further configured to traverse a plurality of second plugins, and call corresponding event processing functions in the second plugins in sequence to process the target event.

Optionally, the processing unit is further configured to determine that the target event passes through an event filter, where the event filter is used to filter out events that do not meet the preset requirement.

Optionally, in the case that the event type is a slot event, the processing unit is further configured to call a corresponding event processing function in the unique second plugin to process the target event.

Optionally, in the case that the event type is a hook event, the processing unit is further configured to traverse the plurality of second plugins, call corresponding event processing functions in the second plugins in sequence, and process the target event, where if any one event processing function return value in the traversal process indicates that the target event has been processed, call corresponding event processing functions in the remaining second plugins is stopped.

Optionally, the target event is registered by: determining an event type, a theme name and an event naming space of the target event; determining an event registration interface of a target event based on the event type, wherein parameters of the event registration interface comprise a theme name and an event naming space; determining a keyword and a unique identifier of a target event through an event registration interface, wherein the keyword comprises an event naming space and a theme name; the key and the unique identifier are stored in association.

Optionally, the processing unit is further configured to send the keyword to a second plugin, where the second plugin determines the unique identifier of the target event based on the event namespace and the topic name included in the keyword; determining a corresponding event processing function in the second plugin through the unique identifier; and processing the target event through the determined event processing function.

Optionally, the target event is subscribed to by the second plugin by: after the target event is successfully registered, determining an event processing function of the target event; determining an event subscription interface based on the event type of the target event; based on the determined event subscription interface, the event handling function is cached and associated with a unique identification of the target event.

According to a third aspect of embodiments of the present disclosure, there is provided an electronic device, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute instructions to implement an event processing method according to the present disclosure.

According to a fourth aspect of embodiments of the present disclosure, there is provided a computer readable storage medium, which when executed by at least one processor, causes the at least one processor to perform an event processing method as described above according to the present disclosure.

According to a fifth aspect of embodiments of the present disclosure, there is provided a computer program product comprising computer instructions which, when executed by a processor, implement an event processing method according to the present disclosure.

The technical scheme provided by the embodiment of the disclosure at least brings the following beneficial effects: according to the event processing method and device, the electronic equipment and the computer readable storage medium, in the process of publishing a target event, a second plugin subscribed to the target event is found through the event name space and the theme name of the target event, so that the second plugin can be called to process the target event, therefore, the communication between two plugins (a first plugin and a second plugin) is carried out through parameters (the event name space and the theme name) in an event publishing interface, even if the parameters of the target event are modified in the process of publishing, only the target event can obtain an error result because of the error parameters, namely, only the event processing result is the error, other events can still be continuously published through the event publishing interface, namely, the second plugin can be called through the event name space and the theme name of the other events, and the communication between the two plugins is not dependent on a code interface any more through the disclosure, so that the problem of binary compatibility is avoided, even if a certain parameter is modified, the plugins can be independently compiled and released, and even if the plugins are not need to be recompiled. Therefore, the method and the device solve the problem that the related technology realizes communication among the plug-ins through the code interface, so that the workload is large.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the disclosure and together with the description, serve to explain the principles of the disclosure and do not constitute an undue limitation on the disclosure.

FIG. 1 is a flowchart illustrating a method of event processing according to an exemplary embodiment;

FIG. 2 is a schematic diagram of a signal event, shown in accordance with an exemplary embodiment;

FIG. 3 is a schematic diagram of a slot event, according to an example embodiment;

FIG. 4 is a schematic diagram of a hook event, shown in accordance with an exemplary embodiment;

FIG. 5 is a schematic diagram illustrating an event registration process according to an example embodiment;

FIG. 6 is a schematic diagram illustrating an event registration flow after determining an event registration interface, according to an example embodiment;

FIG. 7 is a schematic diagram illustrating an event subscription flow in accordance with an example embodiment;

FIG. 8 is a schematic diagram illustrating a signal event subscription flow, according to an example embodiment;

FIG. 9 is a schematic diagram illustrating an event publication flow according to an example embodiment;

FIG. 10 is a schematic diagram illustrating a process of issuing a signaling event, according to an example embodiment;

FIG. 11 is a schematic diagram illustrating a flow of issue slot events according to an example embodiment;

FIG. 12 is a schematic diagram illustrating a flow of issuing a hook event in accordance with an exemplary embodiment;

FIG. 13 is a schematic diagram illustrating a relationship of three events according to an example embodiment;

FIG. 14 is a block diagram of an event processing device, according to an example embodiment;

fig. 15 is a block diagram of an electronic device 1500 according to an embodiment of the disclosure.

Detailed Description

In order to enable those skilled in the art to better understand the technical solutions of the present disclosure, the technical solutions of the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings.

It should be noted that the terms "first," "second," and the like in the description and claims of the present disclosure and in the foregoing figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the disclosure described herein may be capable of operation in sequences other than those illustrated or described herein. The embodiments described in the examples below are not representative of all embodiments consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present disclosure as detailed in the accompanying claims.

It should be noted that, in this disclosure, "at least one of the items" refers to a case where three types of juxtaposition including "any one of the items", "a combination of any of the items", "an entirety of the items" are included. For example, "including at least one of a and B" includes three cases side by side as follows: (1) comprises A; (2) comprising B; (3) includes A and B. For example, "at least one of the first and second steps is executed", that is, three cases are juxtaposed as follows: (1) performing step one; (2) executing the second step; (3) executing the first step and the second step.

An event processing method and apparatus, an electronic device, and a computer-readable storage medium according to exemplary embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.

Fig. 1 is a flowchart illustrating an event processing method according to an exemplary embodiment, and as shown in fig. 1, the event processing method is applied to a first plug-in, and includes the following steps:

in step 101, a processing request is responded to a target event. The target event may be any event that may be processed, such as a opinion publishing event, a new event, a replication event, etc., and the disclosure is not limited.

Returning to FIG. 1, in step 102, an event publishing interface is determined based on the event type of the target event, wherein parameters of the event publishing interface include an event namespace and a topic name of the target event.

Specifically, the event types may be signal events, slot events, or hook events, which is not limited in this disclosure.

According to an exemplary embodiment of the present disclosure, event types may include a signal event, a slot event, and a hook event, wherein in case that the event type of the target event is the signal event, a first plugin registers the target event and issues the target event to the outside, the target event can be subscribed to by a plurality of second plugins, each of which processes the target event; under the condition that the event type of the target event is a slot event, the second plug-in registers the target event and is the only subscriber of the target event, and the first plug-in externally publishes the target event; and under the condition that the event type of the target event is a hook event, the first plugin registers the target event and issues the target event outwards, and the target event can be subscribed by a plurality of second plugins, wherein one plugin in the plurality of second plugins processes the target event. Through the embodiment, three event types are defined, and the three event types cover the service scenes in most of plug-in architecture programs, so that most of service scene requirements can be met, and the method is more flexible than other existing event mechanisms.

Specifically, fig. 2 shows an outline of a signal event, where the signal event is an active event, and when the first plugin uses the signal event as a custom event type, that is, the event type of the first plugin registration event is a signal event, it is common that the first plugin issues the signal event externally, and the other plugins (second plugins) subscribe to this event as subscribers. The usage scenario can be understood as a signal in the Qt signal slot mechanism, but the scope of the signal event is wider, the Qt signal slot is that one object actively sends data to other objects, and the signal event is that one plug-in actively sends data to other plug-ins (although the nature is inter-object communication), and does not care whether other plug-ins subscribe to the event, but just broadcasts. Furthermore, if an event filter is added, the event may be filtered before being released to the outside, and the filtered event cannot be sent.

As an example, one application scenario of the above signal event may be as follows: a user registers in a certain social application to obtain a target account (a first plug-in), then the target account can edit state information on the social application and issue the state information (register and issue target events), other accounts (a second plug-in) on the social application pay attention to (subscribe to) the target account, and then the other accounts can receive the state information issued by the target account and can comment on the state information and the like.

Specifically, fig. 3 shows an outline of a slot event, which is a passive event, contrary to a signal event, when a first plug-in uses the slot event as a custom event type, i.e., the event type of a first plug-in registration event is a slot event, it is usually the other plug-in (second plug-in) that issues the event, and the current plug-in is only the subscriber of the event. A usage scenario may be understood as a slot function in the Qt signal slot mechanism, a slot event may be used when a plug-in wants to provide an interface to the outside, and an event handling function of the slot event may have a return value with respect to the signal event.

As an example, one application scenario for the slot event described above may be as follows: a background plug-in (a second plug-in) of a certain social application defines a state information template (a registered target event), a target account (a first plug-in) on the social application wants to rapidly issue a piece of state information (a target event), and the state information can be issued directly after a proper module is selected from the state information templates in the background plug-in, wherein the social application only has one background plug-in defining the state information template, and therefore, the background plug-in is the only subscriber of the target account, and when the target account wants to rapidly issue the piece of state information, the only background plug-in can be called to rapidly issue the state information.

Specifically, fig. 4 shows an outline of a hook event, which is an active event, and can be understood as a special signal event, unlike a signal event, subscribers to the event will be called one by one in the order of subscription, forming an event execution Sequence (Sequence). During the running of the Sequence of event execution (Sequence), each event processing function must return a pool value as a return value, and if the return is true, indicating that the event processing is complete, the execution Sequence (Sequence) interrupts execution, otherwise continues execution of the next event processing function. A typical application scenario is that a service in a current plug-in has a default processing scenario, but other plug-ins can replace the processing scenario, so that the current plug-in sends a hook event, when a return value is true, the default scenario of the current plug-in is replaced, and related codes can not be run, so that the effect of a hook mechanism is realized.

As an example, one application scenario of the hook event described above may be as follows: a user registers in a certain social application to obtain a target account (a first plug-in), then the target account can edit state information on the social application and release the state information (register and release target events), a background generally sets information released by a plurality of auditors for jointly auditing the registered accounts, namely, the plurality of auditors (a second plug-in) subscribe to the target account, at the moment, when the target account releases the state information, the plurality of auditors can receive the state information and audit the state information, and as long as one auditor audits to pass, other auditors do not need to audit the state information again.

Specifically, the event publishing interface may take different forms according to different event types, for example, when the event type is a signal event, the event publishing interface may take the form of dpfsignal dispatcher- > publishing (const QString & space, const QString & topic, T param, args; for another example, when the event type is a slot event, the event publishing interface may use dpfslotChannel- > push (onst QString & space, const QString & topic, T param, args; for another example, when the event type is a hook event, the event publishing interface may use dpfHooksequence- > run (onst QSTRING & space, onst QSTRING & topic, T param, args. The present disclosure is not limited to the form of the event issue interface described above, and other forms are given in tables 1, 2 and 3, respectively, and will not be discussed here.

Specifically, the theme names may be set according to the needs, and in general, each event may have one theme name, which is set according to the needs, and the disclosure is not limited thereto; in order to avoid duplication of the topic names, each plug-in will have an event namespace, which can be set by the macro interface, and will be described in detail below in the registration stage, which is not discussed here. Thus, an event can be identified by an event namespace and a topic name, thereby ensuring the uniqueness of the event.

Returning to FIG. 1, in step 103, where the target event has been registered and subscribed to, a second plugin is determined that subscribes to the target event based on the event namespace and the topic name, wherein the second plugin is associated with the event namespace, the topic name.

According to an exemplary embodiment of the present disclosure, a target event may be registered by: determining an event type, a theme name and an event naming space of the target event; determining an event registration interface of a target event based on the event type, wherein parameters of the event registration interface comprise a theme name and an event naming space; determining a keyword and a unique identifier of a target event through an event registration interface, wherein the keyword comprises an event naming space and a theme name; the key and the unique identifier are stored in association. By the embodiment, the unique identifier is set, so that the target event can be conveniently identified in the second plug-in unit, and the target event can be conveniently processed; and setting keywords can facilitate communication between two plugins, i.e. the two plugins can utilize keywords comprising event namespaces and topic names.

Specifically, the event namespaces of the above embodiments may be set through a macro interface, which is not limited to this disclosure.

As an example, the macro interface setting the EVENT namespace may be in the form of dpf_event_ NAMESPACE, which may be specifically as follows:

#define DPF_EVENT_NAMESPACE2(space) static constexpr char __KPF_EVENT_ NAMESPACE__[] { #space }；

#define DPF_EVENT_NAMESPACE(spaceMacro) DPF_EVENT_ NAMESPACE2(spaceMacro)；

the essence is to define a compiler constant string, the string is stored based on space parameters transmitted by interface users, and the actual scene usage in the plug-in development framework can be as follows:

#include"dfmplugin_yourpugin_global.h"

header file for # include < dfm-frame work/dpf.h >// providing the event mechanism of the present invention

class YourPlugin : public dpf::Plugin

{

Q_OBJECT

Q_PLUGIN_METADATA(IID"org.deepin.plugin.filemanager"FILE"yourplugin.json")

Namespace for/(and definition events)

The// macro PLUGIN_ NAMESPACE is the plug-in namespace defined in 'dfmplugin_you rpugin_global h'

DPF_EVENT_NAMESPACE(PLUGIN_NAMESPACE)

}；

The macro interface dpf_event_ NAMESPACE in the application example described above will be expanded as a static string member of the class and can be expanded at compile time.

Specifically, the EVENT registration interface of the target EVENT in the above embodiment may be determined based on the EVENT type, for example, when the EVENT type is a SIGNAL EVENT, the EVENT registration interface may use the macro interface dpf_event_reg_signal; for another example, when the EVENT type is a SLOT EVENT, the EVENT registration interface may employ a macro interface dpf_event_reg_slot; for another example, when the EVENT type is a HOOK EVENT, the EVENT registration interface may employ a macro interface dpf_event_reg_hook, which is not limited in this disclosure. The essence of the three event registration interfaces is that the event related identification character strings customized by users are converted into unique digital ids, so that the identification is conveniently carried out inside the plug-in.

Taking the above three macro interfaces as an example, the event registration flow is briefly described, and the implementation of the code modules of the above three macro interfaces may be as follows:

event of registration

#undef DPF_EVENT_REG

#define DPF_EVENT_REG(stratege,topicMacro)

struct DPF_EVENT_##topicMacro

{

DPF_EVENT_##topicMacro()

{

This interface will generate a digital id

dpfEvent->registerEventType(stratege,__KPF_EVENT_NAMESPACE __,#topicMacro);

}

};

DPF_EVENT_##topicMacro _dpf_event_##topicMacro;

#undef DPF_EVENT_REG_SIGNAL

#define DPF_EVENT_REG_SIGNAL(topicMacro) DPF_EVENT_REG(DPF_ NAMESPACE::EventStratege::kSignal, topicMacro)

#undef DPF_EVENT_REG_SLOT

#define DPF_EVENT_REG_SLOT(topicMacro) DPF_EVENT_REG(DPF_ NAMESPACE::EventStratege::kSlot, topicMacro)

#undef DPF_EVENT_REG_HOOK

#define DPF_EVENT_REG_HOOK(topicMacro) DPF_EVENT_REG(DPF_ NAMESPACE::EventStratege::kHook, topicMacro)

It can be seen from the above code templates that the final implementation of the three macro interfaces dpf_event_reg_signal, dpf_event_reg_slot and dpf_event_reg_hook are all done in dpf_event_reg, only different parameters (subject names of EVENTs) are passed to dpf_event_reg, whereas the nature of the implementation of dpf_event_reg is that in the initialization class of the plug-in, a structure class is defined and the structure class object is initialized, by means of the construction function of the structure class object, a globally unique number id is generated according to the subject name of the EVENT.

As an example, the actual scene usage of the three macro interfaces in the plug-in development framework may be as follows:

#include"dfmplugin_yourpugin_global.h"

header file for # include < dfm-frame work/dpf.h >// providing the event mechanism of the present invention

class YourPlugin : public DPF_NAMESPACE::Plugin

{

Q_OBJECT

Q_PLUGIN_METADATA(IID"org.deepin.plugin.filemanager"FILE"yourplugin.json")

Namespace for/(and definition events)

The// macro PLUGIN_ NAMESPACE is the plug-in namespace defined in 'dfmplugin_you rpugin_global h'

// #define PLUGIN_NAMESPACE dfmplugin_yourplugin

DPF_EVENT_NAMESPACE(PLUGIN_NAMESPACE)

Event/registration signal

DPF_EVENT_REG_SIGNAL(signal_ItemClicked)

Event/registration slot

DPF_EVENT_REG_SLOT(slot_CloseTab)

The// registration hook event

DPF_EVENT_REG_HOOK(hook_FileView_FileDrop)

DPF_EVENT_REG_HOOK(hook_FileDialog_FileDrop)

};

The unique digital id corresponding to the event can be generated through the code, and the key of the event and the globally unique digital id are bound and stored, and the specific implementation can be as follows:

void Event::registerEventType(EventStratege stratege, const QString&space, const QString&topic)

{

key of event//

QString key { space +":"+ topic };

if (Q_UNLIKELY(d->eventsMap[stratege].contains(key)))

{

qWarning()<<"Register repeat event:"<< key;

return;

}

QWriteLocker guard(&d->rwLock);

The// geneCustomEventId is an interface to generate an id where a key is bound to an id

d->eventsMap[stratege].insert(key, genCustomEventId());

}

In order to facilitate understanding of the event registration process, the following description of the system is made with reference to fig. 5 and 6, where the event registration process is shown in fig. 5, and fig. 5 illustrates the event registration process, under the c++ plugin development architecture, each plugin should have a plugin initialization class, and the objects of the class are initialized after the plugins are loaded, and only once, where the macro interfaces for event registration (such as the macro interfaces mentioned above) of the present disclosure may be applied. Specifically, a plugin initialization class can be written firstly, an EVENT naming space when the plugin registers an EVENT is set based on DPF_event_ NAMESPACE, then an EVENT type of the registration EVENT, such as a SIGNAL EVENT (SIGNAL EVENT), a slot EVENT (slot EVENT) or a hook EVENT (hook EVENT), is determined, and a related EVENT registration interface registration EVENT is called based on the EVENT type, such as a macro interface DPF_event_REG_SIGNAL when the EVENT type is the SIGNAL EVENT; for another example, when the EVENT type is a SLOT EVENT, the EVENT registration interface may employ a macro interface dpf_event_reg_slot; for another example, when the EVENT type is a HOOK EVENT, the EVENT registration interface may employ a macro interface dpf_event_reg_hook.

The above three event registration interfaces are similar in registration process, as shown in fig. 6, fig. 6 shows an event registration process after determining the event registration interface, firstly, initializing an initialization class and an event topic class of a plug-in, then acquiring a keyword (key) of a registration event based on an event naming space and a topic name, generating a globally unique digital id, and binding and storing the generated keyword and the digital id.

In particular, the keywords of the above embodiment may be event namespaces and topic names themselves, or may be changed in form, which is not limited to this disclosure. The disclosed embodiments are based on event namespaces and topic names themselves.

According to an exemplary embodiment of the present disclosure, the target event may be subscribed to by the second plugin by: after the target event is successfully registered, determining an event processing function of the target event; determining an event subscription interface based on the event type of the target event; based on the determined event subscription interface, the event handling function is cached and associated with a unique identification of the target event. According to the embodiment, the event processing function is cached and is associated with the unique identifier of the target event, and the unique identifier is associated with the event naming space and the theme name when registering, namely, the event processing function is associated with the event naming space and the theme name, so that when the event naming space and the theme name are received when communication between plugins is carried out according to binding among parameters, the corresponding event processing function can be determined through the unique identifier.

Specifically, the event subscription interface in the above embodiment may be determined based on the event type, for example, when the event type is a signal event, the event subscription interface may employ dpfSignalDispatch->subscribe（const QString&space，const QString&topic，Func method); for another example, when the event type is a slot event, the event subscription interface may employ dpfslotChannel->connect（onst QString&space，const QString&topic，/>Func method); for another example, when the event type is a hook event, the event subscription interface may employ dpfHooksequence->follow（onst QString&space，const QString&topic，/>Func method), wherein const QSTRING&space is the event namespace at event registration, const QSTRING&topic is the topic name of the event, +.>Func method is an event handling function for object pointers of the handling function. The present disclosure is not limited to the form of the event subscription interface described above, and other forms are given below by tables 1, 2 and 3, respectively, and will not be discussed further herein.

The following takes the above three event subscription interfaces as an example, and the event subscription flow is briefly described.

After the target event is successfully registered, which corresponds to a specific event, the target event needs to be subscribed to, and fig. 7 shows an event subscription flow, as shown in fig. 7, where an event processing interface of the target event needs to be defined first, that is, a receiver object (corresponding to a second plugin) of the target event needs to be defined, that is, if one plugin can process a plurality of different events, then there may be a plurality of receiver objects of different events in the plugin), and the object is a meta-type object of Qt, and an event processing function (such as a slot function of Qt) needs to be specified. Code defining the recipient object and the event handling function may be as follows:

Event receiver class

class EventReceiver: public QObject

{

Q_OBJECT

Q_DISABLE_COPY(EventReceiver)

public:

The pointer to the instance object is/is returned, typically a single object

The/(slot) function as an event handling interface function

public slots:

void handleOpenNewWindow(quint64 winID);

void handleStartSearch(quint64 winID, const QString&text);

Other event handling functions

};

As shown in fig. 7, after defining the event processing interface, an event subscription interface needs to be determined based on the event type, that is, a corresponding event subscription interface needs to be called based on the event type to subscribe to a target event, for example, when the event type is a signal event, the event subscription interface may adopt a dpfsignalDispatcher- > substricriber; for another example, when the event type is a slot event, the event subscription interface may employ dpfSlotChannel- > connect; for another example, when the event type is a hook event, the event subscription interface may employ dpfHooksequence- > follow.

It should be noted that, to subscribe to a specific Event and bind an Event handling function, a single instance object of each Event type is defined according to the Event class defined in the following table 4: DPF_ NAMESPACE:: event:: instance (), namely defining Manager classes of three Event types respectively, wherein each Manager class comprises a plurality of class objects belonging to the corresponding Event type, the Manager classes are associated with the Event classes, the external interfaces are finally provided by the Event classes, and the Manager class objects are exposed externally.

The subscription procedure will be described below separately by event types including a signal event (signal event), a slot event (slot event), and a hook event (hook event).

1. subscription process of signal event:

first, the eventdispatchermnager class object in table 4 below needs to be acquired, and the event subscription and publishing are performed through its interface: # define dpfSignalDispatcher dpfEvent- > dispatcher ().

Then, a corresponding event subscription interface dpfsignalDispatch- > subscore is used to subscribe to a signal event, one signal event can be subscribed multiple times, and the subscription code implementation can be as follows:

the/subscription to a signal event, which is typically defined by other plug-ins

dpfSignalDispatcher->subscribe("dfmplugin_titlebar","signal_StartSearch", EventReceiver::instance(),&EventReceiver::handleStartSearch);

The logic essence of the implementation is that the receiver object of the event and the event processing function are cached and then mapped with the unique identifier of the event, and the logic flow is shown in fig. 8 and mainly comprises the following steps:

1) When event subscription interface dpfSignaldispatcher->After the subscore is called, a relational database for binding and storing the keyword character strings and the event ids in the previous event registration needs to be found, the event ids are acquired, then the event ids enter a same-name reload function eventdispatchermnager based on the acquired event ids (EventType, Func method), checking whether the event has been subscribed to;

2) If the event is subscribed, the existing EventDispatcher object (the object corresponding to the current event in the signal event class) is directly taken out from the object cached by the EventDispatch manager (the signal event class), then the receiver object (i.e. the event processing object) of the subscribed event and the event processing function are added into the object cached by the current event, so that the plug-in which is subscribed to the current event can be known through the content cached under the object of the current event;

3) If the event is not subscribed, a new EventDispatcher object is created in the EventDispatchManager, and then a receiver object (i.e. an event processing object) of the subscribed event and an event processing function are added to be cached under the object of the current event;

4) And finishing subscription and waiting for calling.

2. subscription process of slot event:

first, the EventChannelManager class object in the following table 4 needs to be acquired, and the event subscription and publishing are performed through its interface: # define dpfSlotChannel dpfEvent- > channel ().

Then, a corresponding event subscription interface dpfslotChannel- > connect is used for subscribing the slot event, one slot event can be subscribed only once, the plug-in which the subscriber is located and the plug-in which the event is registered are the same plug-in, and the implementation of the subscription code can be as follows:

The// subscription is to a slot event, which is usually defined by the plug-in itself

The you/event handling function YouPluginEventReceiver:: handleCloseTab may have a return value

dpfSlotChannel->connect("dfmplugin_yourplugin","slot_CloseTab", receiverPtr,&YourPluginEventReceiver::handleCloseTab);

The implementation logic nature of the event subscription is basically consistent with the implementation of the signal event subscription, but the function of the subscription becomes EventChannelManager:: connect, and the event can only be subscribed by one event processing object. Since the subscription flow is substantially identical to the signal event subscription flow, discussion is not presented herein.

3. Subscription process of hook event:

first, the EventSequenceManager class object in table 4 below needs to be acquired, and the event subscription and publishing are performed through its interface: # define dpfHookSequence dpfEvent- > sequence ()

Then, a corresponding event subscription interface dpfHooksequence > follow is used to subscribe to the hook events, one hook event can be subscribed to multiple times, and the subscription code implementation can be as follows:

a hook event for a custom event is/is subscribed to, typically defined by other plug-ins

dpfHookSequence->follow("dfmplugin_workspace","hook_FetchCustomColumnRoles", RecentManager::instance(),&RecentManager::customColumnRole);

The implementation logic nature of the event subscription is basically consistent with the implementation of the signal event subscription, but the subscription function becomes EventSequenceManager:: follow, and the event can only be subscribed by one event processing object. Since the subscription flow is substantially identical to the signal event subscription flow, discussion is not presented herein.

According to an exemplary embodiment of the present disclosure, determining the second plugin subscribed to the target event based on the event namespace and the topic name in step 102 may include: determining a class object of the event type; based on the event namespaces and the topic names, the object of the target event is obtained from the class object of the event type, wherein the object contains a second plugin subscribed to the target event. According to the embodiment, the second plug-in subscribed to the target event can be conveniently and quickly determined.

As an example, when the event type is a signal event, the class object is an eventdispatchermnager, when the event type is a slot event, the class object is an EventChannelManager, when the event type is a hook event, the class object is an EventSequenceManager, so after determining the corresponding class object based on the event type, the object of the target event in the class object can be determined based on the event name space and the topic name, then based on the event name space and the topic name, the unique identification of the event is determined, and the corresponding event processing function stored in the object of the target event is determined based on the unique identification, namely, the second plugin subscribed to the target event is determined.

Returning to FIG. 1, in step 104, a second plug-in is invoked to process the target event.

According to an exemplary embodiment of the present disclosure, invoking the second plug-in to process the target event may include: the method comprises the steps that a keyword is sent to a second plug-in, wherein the second plug-in determines a unique identifier of a target event based on an event name space and a theme name included by the keyword; determining a corresponding event processing function in the second plugin through the unique identifier; and processing the target event through the determined event processing function. Through the embodiment, the plug-ins communicate through the keywords, the event is identified and processed through the identification in the plug-ins, so that the plug-ins do not communicate through the code interface any more, the problem of binary compatibility is avoided, and each plug-in can be compiled and issued independently.

As can be seen from the event processing method illustrated in fig. 1, the publishing of an event not only needs to be registered, but also needs to be subscribed, that is, there is a corresponding event processing function, and the following describes a target event publishing flow in brief with the above-mentioned three event publishing interfaces, and fig. 9 illustrates an event publishing flow, and as shown in fig. 9, determines a corresponding event publishing interface based on an event type, and invokes the corresponding event publishing interface, if a target event is registered and subscribed, a corresponding event processing function is found, for example, a publishing plug-in (a first plug-in) sends an event naming space and a theme name to a second plug-in, and the second plug-in determines a unique identifier of the target event based on the received content, and determines a corresponding event processing function in the second plug-in through the unique identifier, that is, that finds the event processing function, and processes the target event through the event processing function.

It should be noted that, to publish an event, the event must be registered and subscribed, otherwise, the event publish process is terminated.

The event distribution process will be described below separately by event types including a signal event (signal event), a slot event (slot event), and a hook event (hook event).

According to an exemplary embodiment of the present disclosure, in a case where the event type is a signal event, wherein the second plugin is invoked to process the target event, the method may include: traversing the plurality of second plugins, and sequentially calling corresponding event processing functions in the second plugins to process the target event. Through the embodiment, the target event may be a signal event, at this time, the published target event may be subscribed by a plurality of second plugins, and the plurality of plugins may all process the target event, thereby increasing a one-to-many inter-plugin communication scenario.

Specifically, when the target event is a signal event, the event publishing interface dpfsignalDispatch- > publishing may be used to synchronously publish the signal event, where the published signal event is in a one-to-many form, i.e. all subscribers will receive the event, and the code implementation of the published event may be as follows:

The/send a signal event, typically defined by the sender plug-in itself

dpfSignalDispatcher->publish("dfmplugin_titlebar","signal_StartSearch", winId,"test");

The/send a signal event but does not match the event handling function parameters of the receiver, so the receiver cannot handle

bool ret3 = dpfSignalDispatcher->publish("dfmplugin_titlebar","signal_ StartSearch","test", winId);

As an example, fig. 10 shows a publishing flow of publishing a signal event using dpfsignal dispatcher- > publishing, and as shown in fig. 10, mainly includes the following steps:

1. when an event publishing interface dpfsignalDispatcher- > publich is called, a relation database for binding and storing a keyword character string and an event id in the previous event registration is required to be found, the event id is acquired, and then whether the event is subscribed or not is checked based on the fact that the acquired event id enters a homonymous heavy load function EventDispatcherManager: publish (EventType type);

2. if the event has been subscribed, finding an EventDispatcher object subscribing to the event;

3. invoking EventDispatcher by dispatch, traversing all subscriber objects subscribing to the event, i.e. traversing all recipient objects in the EventDispatcher object;

4. checking whether the event is filtered or not, and if not, calling each event processing function subscribed to the event one by one.

According to an exemplary embodiment of the present disclosure, before the second plug-in is invoked to process the target event, it may be determined that the target event passes through an event filter, where the event filter is used to filter out events that do not meet the preset requirements. By this embodiment, unwanted events can be prevented from being issued, causing unnecessary losses.

By way of example, if the target event does not pass the event filter, i.e., is filtered, then no corresponding event handler need be invoked, avoiding undesirable events, resulting in unnecessary losses.

According to an exemplary embodiment of the present disclosure, in a case where the event type is a slot event, wherein the second plugin is invoked to process the target event, the method may include: and calling a corresponding event processing function in the unique second plug-in to process the target event. Through the embodiment, the target event may be a slot event, and at this time, the published event is subscribed only by one second plugin, so that a one-to-one inter-plugin communication scenario is increased.

Specifically, when the target event is a slot event, the slot event can be synchronously published by using an event publishing interface dpfSlotChannel- > push, the published slot event is in a one-to-one form, a unique subscriber will receive the event, and the code implementation of the published event can be as follows:

Slot event of/sending a custom event, typically defined by other plug-ins

const QVariant&ret = dpfSlotChannel->push("dfmplugin_yourplugin","slot_CloseTab", url);

As an example, fig. 11 shows a publishing flow of a dpfSlotChannel- > push publishing slot event, as shown in fig. 11, mainly including the following steps:

1. when an event publishing interface dpfslotChannel- > push is called, a relation database for binding and storing a keyword character string and an event id in the previous event registration is required to be found, the event id is acquired, and then whether the event is subscribed or not is checked based on the acquired event id entering a homonymous heavy load function EventChannelManager: push (EventType type);

2. if the event has been subscribed, finding an EventChannel object subscribing to the event;

3. calling EventChannel from send, wherein the subscriber object in the found EventChannel object is necessarily unique, so that an event processing function of the subscriber object is directly called;

4. and acquiring a return value QVariant object of the event processing function as a return value of the event release interface.

According to an exemplary embodiment of the present disclosure, in a case where the event type is a hook event, wherein the second plugin is invoked to process the target event, the method may include: and traversing the plurality of second plugins, sequentially calling corresponding event processing functions in the second plugins, and processing the target event, wherein if any event processing function return value in the traversal process indicates that the target event is processed, the calling of the corresponding event processing functions in the rest second plugins is stopped. Through the embodiment, the target event can be a hook event, and the published event can be subscribed by a plurality of second plugins at the same time, but only one plugin can process the target event, so that a one-to-many inter-plugin communication scene is increased.

Specifically, when the target event is a hook event, the hook event can be synchronously published by using an event publishing interface dpfHookSequence- > run, the published hook event is in a one-to-many form, all subscribers (subscriber sequences) thereof receive the target event according to the subscription sequence, an event processing function of the target event must return a book value, if the value is true, namely the return value indicates that the target event has been processed, the event processing function of the subsequent subscribers is not executed any more, the execution sequence is interrupted, and otherwise, the sequence is continued to be executed. The code implementation of the post event may be as follows:

a hook event is sent/sent by a custom event, which is typically defined by the plug-in itself

Any event handling function in the sequence returns true, then run returns true, otherwise false.

bool ret = dpfHookSequence->run("dfmplugin_workspace","hook_FetchCustom ColumnRoles", rootUrl, roleList);

As an example, fig. 12 illustrates a release flow of releasing a hook event using dpfHookSequence- > run, and as shown in fig. 12, mainly includes the following steps:

1. when an event publishing interface dpfHooksequence- > run is called, a relation database for binding and storing a keyword character string and an event id in the previous event registration is required to be found, the event id is obtained, and then whether the event is subscribed or not is checked based on the fact that the obtained event id enters a homonymous heavy load function EventSequence manager: run (EventType type);

2. If the event has been subscribed, finding an EventSequence object subscribing to the event;

3. calling an EventSequence function, namely traversing all subscriber objects subscribing the event according to the subscription order, and then sequentially executing corresponding event processing functions, namely traversing all receiver objects in the EventSequence object;

4. if any event handling function in the traversal process returns a true value, the traversal of the event handling function is terminated, and all remaining calls to the event handling function are ignored.

It should be noted that, in the above embodiments of the present disclosure, the forms of interfaces, such as the event registration interface, the event subscription interface, and the event publishing interface, may have various forms, which are not limited to the forms mentioned in the above embodiments, but may also have an unsubscribe interface, an asynchronous transmission interface, and the like, and the present disclosure is not limited to the examples, and the following lists the forms of interfaces that may be used by table 1, table 2, table 3, and table 4.

Table 1 EventDispatcherManager signal event interface table

/>

/>

Table 2 EventChannelManager slot event interface table

/>

Table 3 EventSequenceManager hook event interface table

Table 4 Event interface table

It should be noted that the three event types are relatively independent but are related to each other. The external interface of the signal event (signal event) is realized by the EventDispatcher class, the external interface of the slot event (slot event) is realized by the EventChannelManager class, and the external interface of the hook event (hook event) is realized by the EventSequenceManager class, and the relation between them is shown in FIG. 13.

In summary, the present disclosure realizes an event communication mechanism of a c++ object under a pluggable architecture, targeting low coupling and guaranteeing sufficient performance, guaranteeing that each plug-in can be compiled and issued independently, and there is no data coupling between the plug-in and the plug-in, so as to solve the code coupling problem of the object communication between the conventional plug-ins, and in addition, the present disclosure provides 3 communication models (signal event, slot event, hook event), so as to satisfy most of service scene requirements, and solve the problem of single mode of the object communication between the conventional plug-ins.

Fig. 14 is a block diagram illustrating an event processing apparatus according to an example embodiment. Referring to fig. 14, the apparatus includes a target event issue interface determination unit 142, a second plug-in determination unit 144, and a processing unit 146.

A publishing interface determining unit 142 configured to determine an event publishing interface based on an event type of the target event in response to a processing request of the target event, wherein parameters of the event publishing interface include an event namespace and a topic name of the target event; a second plugin determining unit 144 configured to determine, in a case where the target event has been registered and subscribed, a second plugin subscribed to the target event based on the event namespace and the topic name, wherein the second plugin is associated with the event namespace, the topic name; and a processing unit 146 configured to call the second plug-in and process the target event.

According to an exemplary embodiment of the present disclosure, event types include a signal event, a slot event, and a hook event, wherein in a case where the event type of the target event is the signal event, a first plugin registers the target event and issues the target event to the outside, the target event can be subscribed to by a plurality of second plugins, each of which processes the target event; under the condition that the event type of the target event is a slot event, the second plug-in registers the target event and is the only subscriber of the target event, and the first plug-in externally publishes the target event; and under the condition that the event type of the target event is a hook event, the first plugin registers the target event and issues the target event outwards, and the target event can be subscribed by a plurality of second plugins, wherein one plugin in the plurality of second plugins processes the target event.

According to an exemplary embodiment of the present disclosure, in a case where the event type is a signal event, the processing unit 146 is further configured to traverse the plurality of second plugins, and sequentially call corresponding event processing functions in the second plugins, to process the target event.

According to an exemplary embodiment of the present disclosure, the processing unit 146 is further configured to determine that the target event passes through an event filter before invoking the second plug-in to process the target event, where the event filter is used to filter out events that do not meet the preset requirements.

According to an exemplary embodiment of the present disclosure, in case the event type is a slot event, wherein the processing unit 146 is further configured to invoke a corresponding event handling function in the unique second plugin for handling the target event.

According to an exemplary embodiment of the present disclosure, in a case where the event type is a hook event, the processing unit 146 is further configured to traverse a plurality of second plugins, call corresponding event processing functions in the second plugins in turn, and process the target event, where if any one event processing function return value in the traversal process indicates that the target event has been processed, call of corresponding event processing functions in the remaining second plugins is stopped.

According to an exemplary embodiment of the present disclosure, a target event is registered by: determining an event type, a theme name and an event naming space of the target event; determining an event registration interface of a target event based on the event type, wherein parameters of the event registration interface comprise a theme name and an event naming space; determining a keyword and a unique identifier of a target event through an event registration interface, wherein the keyword comprises an event naming space and a theme name; the key and the unique identifier are stored in association.

According to an exemplary embodiment of the present disclosure, the processing unit 146 is further configured to send the keyword to a second plugin, wherein the second plugin determines the unique identification of the target event based on the event namespace and the topic name included by the keyword; determining a corresponding event processing function in the second plugin through the unique identifier; and processing the target event through the determined event processing function.

According to an exemplary embodiment of the present disclosure, the target event is subscribed to by the second plugin by: after the target event is successfully registered, determining an event processing function of the target event; determining an event subscription interface based on the event type of the target event; based on the determined event subscription interface, the event handling function is cached and associated with a unique identification of the target event.

According to embodiments of the present disclosure, an electronic device may be provided. Fig. 15 is a block diagram of an electronic device 1500 that includes at least one memory 1501 and at least one processor 1502 having stored therein a set of computer executable instructions 15011 and an operating system 15012 that, when executed by the at least one processor, perform an event processing method according to an embodiment of the present disclosure, according to an embodiment of the present disclosure.

By way of example, electronic device 1500 may be a PC computer, tablet device, personal digital assistant, smart phone, or other device capable of executing the above-described set of instructions. Here, the electronic device 1500 is not necessarily a single electronic device, but may be any apparatus or a collection of circuits capable of executing the above-described instructions (or instruction sets) individually or in combination. The electronic device 1500 may also be part of an integrated control system or system manager, or may be configured as a portable electronic device that interfaces with either locally or remotely (e.g., via wireless transmission).

In electronic device 1500, processor 1502 may include a Central Processing Unit (CPU), a Graphics Processor (GPU), a programmable logic device, a special purpose processor system, a microcontroller, or a microprocessor. By way of example, and not limitation, the processor 1502 may also include an analog processor, a digital processor, a microprocessor, a multi-core processor, a processor array, a network processor, and the like.

The processor 1502 may execute instructions or code stored in a memory, wherein the memory 1501 may also store data. The instructions and data may also be transmitted and received over a network via a network interface device, which may employ any known transmission protocol.

The memory 1501 may be integrated with the processor 1502, such as by disposing RAM or flash memory within an integrated circuit microprocessor or the like. In addition, the memory 1501 may include a separate device, such as an external disk drive, a storage array, or other storage device usable by any database system. The memory 1501 and the processor 1502 may be operatively coupled or may communicate with each other, for example, through an I/O port, a network connection, etc., so that the processor 1502 can read files stored in the memory 1501.

In addition, electronic device 1500 may also include a video display (such as a liquid crystal display) and a user interaction interface (such as a keyboard, mouse, touch input device, etc.). All components of the electronic device may be connected to each other via a bus and/or a network.

According to an embodiment of the present disclosure, there may also be provided a computer-readable storage medium, wherein instructions in the computer-readable storage medium, when executed by at least one processor, cause the at least one processor to perform the event processing method of the embodiments of the present disclosure. Examples of the computer readable storage medium herein include: read-only memory (ROM), random-access programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), random-access memory (RAM), dynamic random-access memory (DRAM), static random-access memory (SRAM), flash memory, nonvolatile memory, CD-ROM, CD-R, CD + R, CD-RW, CD+RW, DVD-ROM, DVD-R, DVD + R, DVD-RW, DVD+RW, DVD-RAM, BD-ROM, BD-R, BD-R LTH, BD-RE, blu-ray or optical disk storage, hard Disk Drives (HDD), solid State Disks (SSD), card memory (such as multimedia cards, secure Digital (SD) cards or ultra-fast digital (XD) cards), magnetic tape, floppy disks, magneto-optical data storage, hard disks, solid state disks, and any other means configured to store computer programs and any associated data, data files and data structures in a non-transitory manner and to provide the computer programs and any associated data, data files and data structures to a processor or computer to enable the processor or computer to execute the programs. The computer programs in the computer readable storage media described above can be run in an environment deployed in a computer device, such as a client, host, proxy device, server, etc., and further, in one example, the computer programs and any associated data, data files, and data structures are distributed across networked computer systems such that the computer programs and any associated data, data files, and data structures are stored, accessed, and executed in a distributed fashion by one or more processors or computers.

According to an embodiment of the present disclosure, there is provided a computer program product comprising computer instructions which, when executed by a processor, implement the event processing method of the embodiments of the present disclosure.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This disclosure is intended to cover any adaptations, uses, or adaptations of the disclosure following the general principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It is to be understood that the present disclosure is not limited to the precise arrangements and instrumentalities shown in the drawings, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims (12)

1. An event processing method, applied to a first plugin, comprising:

determining an event release interface based on an event type of a target event in response to a processing request of the target event, wherein parameters of the event release interface comprise an event name space and a theme name of the target event;

Determining a second plugin subscribed to the target event based on the event namespace and the topic name, where the second plugin is associated with the event namespace, the topic name, where the target event has been registered and subscribed to;

and calling the second plug-in to process the target event.

2. The event processing method of claim 1, wherein the event types include a signal event, a slot event, and a hook event, wherein,

when the event type of the target event is a signal event, the first plugin registers the target event and externally issues the target event, the target event can be subscribed by a plurality of second plugins, and the plurality of second plugins process the target event;

when the event type of the target event is a slot event, the second plugin registers the target event and is the only subscriber of the target event, and the first plugin issues the target event to the outside;

and under the condition that the event type of the target event is a hook event, the first plugin registers the target event and issues the target event outwards, the target event can be subscribed by a plurality of second plugins, and one plugin in the plurality of second plugins processes the target event.

3. The event processing method according to claim 2, wherein, in a case where the event type is a signal event, the invoking the second plug-in to process the target event includes:

and traversing the plurality of second plugins, and sequentially calling corresponding event processing functions in the second plugins to process the target event.

4. The event processing method of claim 3, further comprising:

and determining that the target event passes through an event filter, wherein the event filter is used for filtering out events which do not meet preset requirements.

5. The event processing method according to claim 2, wherein, in a case where the event type is a slot event, the invoking the second plug-in to process the target event includes:

and calling a corresponding event processing function in the unique second plug-in to process the target event.

6. The event processing method according to claim 2, wherein, in a case where the event type is a hook event, the invoking the second plug-in to process the target event includes:

And traversing the plurality of second plugins, sequentially calling corresponding event processing functions in the second plugins, and processing the target event, wherein if any event processing function return value in the traversing process indicates that the target event is processed, the calling of the corresponding event processing functions in the rest second plugins is stopped.

7. The event processing method as claimed in claim 1, wherein the target event is registered by:

determining the event type, the topic name, and the event namespace of the target event;

determining an event registration interface of the target event based on the event type, wherein parameters of the event registration interface comprise the topic name and the event namespace;

determining a keyword and a unique identifier of the target event through the event registration interface, wherein the keyword comprises the event name space and the topic name;

and storing the key words and the unique identification in an associated mode.

8. The event processing method as set forth in claim 7, wherein said invoking said second plug-in to process said target event comprises:

The keyword is sent to the second plug-in, wherein the second plug-in determines the unique identification of the target event based on the event name space and the topic name included by the keyword; determining a corresponding event processing function in the second plugin through the unique identifier; and processing the target event through the determined event processing function.

9. The event processing method of claim 7, wherein the target event is subscribed to by the second plugin by:

after the target event is successfully registered, determining an event processing function of the target event;

determining an event subscription interface based on the event type of the target event;

based on the determined event subscription interface, the event handling function is cached and associated with a unique identification of the target event.

10. An event processing apparatus, comprising:

a release interface determining unit configured to determine an event release interface based on an event type of a target event in response to a processing request of the target event, wherein parameters of the event release interface include an event namespace and a topic name of the target event;

A second plugin determining unit configured to determine, in a case where the target event has been registered and subscribed, a second plugin subscribed to the target event based on the event namespace and the topic name, wherein the second plugin is associated with the event namespace, the topic name;

and the processing unit is configured to call the second plug-in and process the target event.

11. An electronic device, comprising:

a processor;

a memory for storing the processor-executable instructions;

wherein the processor is configured to execute the instructions to implement the event processing method of any of claims 1 to 9.

12. A computer-readable storage medium, wherein instructions in the computer-readable storage medium, when executed by at least one processor, cause the at least one processor to perform the event processing method of any of claims 1 to 9.