Method, device, equipment, medium and program product for generating context menu

Abstract

The present disclosure relates to the technical field of computer, and provides a context menu generation method, device, equipment, medium and program product. The context menu generation method comprises: after receiving a menu trigger operation for a target object, obtaining menu configuration data, related permission configuration data and context state data previously set for the target object, wherein the menu configuration data contains at least one initial menu item. The initial menu items are screened by using a verification rule to determine a set of menu items to be displayed; the verification rule contains a verification rule based on the permission configuration data and a verification rule based on the context state data, and each initial menu item is configured to be associated with a first verification rule and / or a second verification rule. According to the configuration attributes of each menu item in the set of menu items to be displayed, a context menu for the target object is generated and displayed. The present disclosure improves the flexibility of the menu generation process and the accuracy of the menu item display.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and specifically to methods, apparatus, devices, media, and program products for generating context menus. Background Technology

[0002] With the rapid development of human-computer interaction technology, context menus are an important entry point for users to perform interactive operations on objects. In related technologies, the content of context menu items is usually statically configured, making it difficult to flexibly adapt to different objects. Regarding permission filtering for menu items, existing technologies lack a unified filtering mechanism, relying solely on a single judgment method to control the display of menu items. This fails to simultaneously address the verification requirements based on server-side permission data and local state data, resulting in discrepancies between the displayed menu items and the user's actual permissions and current state, thus impacting the user experience.

[0003] Therefore, there is an urgent need for a method to generate context menus to solve the problems of inaccurate and inflexible menu item display in related technologies. Summary of the Invention

[0004] This disclosure provides a method, apparatus, device, medium, and program product for generating context menus to solve the problems of inaccurate and inflexible menu item display in related technologies.

[0005] In a first aspect, embodiments of this disclosure provide a method for generating a context menu, the method comprising: In response to a menu trigger operation targeting a target object, obtain the menu configuration data configured for the target object, as well as the permission configuration data and context state data associated with the target object. The menu configuration data contains at least one initial menu item. The initial menu items are filtered based on the verification rules to determine the set of menu items to be displayed; wherein, the verification rules include a first verification rule based on permission configuration data and a second verification rule based on context state data, and each initial menu item is configured to be associated with the first verification rule and / or the second verification rule; Generate and display a context menu for the target object based on the configuration properties of each menu item in the set of menu items to be displayed.

[0006] Secondly, embodiments of this disclosure provide an apparatus for generating a context menu, the apparatus comprising: The acquisition module is used to acquire menu configuration data configured for the target object, as well as permission configuration data and context state data associated with the target object, in response to a menu trigger operation for the target object. The menu configuration data includes at least one initial menu item. The filtering module is used to filter the initial menu items based on the verification rules to determine the set of menu items to be displayed; wherein, the verification rules include a first verification rule based on permission configuration data and a second verification rule based on context state data, and each initial menu item is configured to be associated with the first verification rule and / or the second verification rule; The generation module is used to generate and display a context menu for a target object based on the configuration attributes of each menu item in the set of menu items to be displayed.

[0007] Thirdly, embodiments of this disclosure provide an electronic device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the context menu generation method of the first aspect or any corresponding embodiment described above.

[0008] Fourthly, embodiments of this disclosure provide a computer-readable storage medium storing computer instructions for causing a computer to execute the context menu generation method of the first aspect or any corresponding embodiment described above.

[0009] Fifthly, embodiments of this disclosure provide a computer program product, including computer instructions for causing a computer to execute the method for generating a context menu according to the first aspect or any corresponding embodiment.

[0010] The context menu generation method provided in this disclosure pre-configures menu configuration data for the target object and pre-configures the association relationship between each initial menu item and the validation rules in the menu configuration data, thereby achieving the classification and validation of menu items of different natures. As a result, the filtering logic of each menu item is independent and does not interfere with each other, accurately determining the set of menu items to be displayed. Then, a context menu for the target object is generated and displayed based on the configuration attributes of each menu item, avoiding the problem of inaccurate menu item display caused by mixed validation logic. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the specific embodiments of this disclosure or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram illustrating an application scenario according to an embodiment of this disclosure; Figure 2This is a schematic flowchart of a first method for generating a context menu according to an embodiment of the present disclosure; Figure 3 This is a schematic diagram of a second method for generating a context menu according to an embodiment of the present disclosure; Figure 4 This is a schematic diagram of the system architecture of the right-click menu management system for a voice social client based on the PyQt5 framework according to an embodiment of this disclosure; Figure 5 This is a schematic diagram of the execution flow of a right-click menu management system for a voice social client based on the PyQt5 framework according to an embodiment of this disclosure; Figure 6 This is a timing diagram illustrating the interactions of the various modules according to embodiments of this disclosure; Figure 7 This is a schematic diagram of the state machine of the menu management module according to an embodiment of the present disclosure; Figure 8 This is a structural block diagram of a context menu generation apparatus according to an embodiment of the present disclosure; Figure 9 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this disclosure. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0014] It should be noted that the information (including but not limited to user input information, such as information entered into input boxes), data (including but not limited to data used for analysis, stored data, and displayed data, such as context code, all code of the current project, service pressure corresponding to operations performed on all code of the current project, and code development status of the current project), and signals involved in this disclosure are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with relevant laws, regulations, and standards. For example, the context code, operations performed on all code of the current project, the corresponding service pressure, and code development status involved in this disclosure were all obtained with full authorization.

[0015] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this disclosure, "a plurality of" means two or more, unless otherwise expressly specified.

[0016] Before providing a detailed description of the embodiments of this disclosure, some of the nouns and terms involved in the embodiments of this disclosure will be explained.

[0017] (1) PyQt5: A graphical user interface development framework for the Python language, based on the Qt5 library, providing a rich set of desktop application controls.

[0018] (2) QMenu: A control class in PyQt5 used to create context menus (pop-up menus).

[0019] (3) QWidgetAction: An action class in PyQt5 that allows custom controls (such as sliders, checkboxes, etc.) to be embedded in menu items. It inherits from QAction.

[0020] (4) QListWidget: A control in PyQt5 used to display list items, supporting interactive states such as selection and disabling.

[0021] (5) QSlider: A slider control in PyQt5 that allows users to input continuous values ​​within a specified range by dragging.

[0022] (6) QCheckBox: A checkbox control in PyQt5, representing a state switch that can be checked or unchecked independently.

[0023] (7) QRadioButton: A radio button control in PyQt5 used to select one of a set of mutually exclusive options.

[0024] (8) MenuHelper (menu configuration module): This module is responsible for pre-defining the menu configuration data for each scene. It is the "description layer" of the menu content and completely decouples the definition of menu items from runtime rendering.

[0025] (9) MenuManager (Menu Management Module): The core management module for menu generation and scheduling, responsible for reading configuration, driving filtering, generating controls and finally displaying the menu.

[0026] (10) MenuFilter (permission filtering module): The module that maintains the mapping relationship between menu items and validation functions and executes filtering logic.

[0027] (11) roleMenu: MenuFilter stores a mapping table of menu items that "require server permission judgment" and their corresponding validation functions.

[0028] (12) localLogicMenu: MenuFilter stores a mapping table of menu items that "require local logic judgment" and their corresponding validation functions.

[0029] (13) ActionFunction (control encapsulation module): a module that encapsulates the creation logic of various QWidgetActions and provides a unified interface to the outside world.

[0030] (14) getColorfulTextAction: A method in ActionFunction used to create menu items with custom colored text.

[0031] (15) getCheckBoxBtnAction: A method in ActionFunction used to create menu items with checkbox controls.

[0032] (16) getRadioBtnAction: A method in ActionFunction used to create menu items with radio button controls.

[0033] (17) getSliderAction: A method in ActionFunction used to create menu items with slider controls.

[0034] (18) MenuRoleObject (role management module): This module is responsible for dynamically obtaining the list of room or space roles and controlling the operable status of each role's menu items according to the permission level.

[0035] (19) MenuVoiceChannelObject (Channel Scheduling Module): This module is responsible for displaying a list of schedulable target channels and supporting capacity verification and disabling prompts.

[0036] (20) Requester (data request module): The module responsible for asynchronously pulling data such as permissions, roles, mute, and orders from the server before the menu is displayed.

[0037] (21) Done signal: The notification signal sent by Requester to MenuManager after completing asynchronous data loading, which triggers the formal generation and display process of the menu.

[0038] (22) MenuPositionAdapter (position adaptation module): A module that automatically calculates and adjusts the coordinates of the pop-up menu based on the boundaries of the main window and the actual size of the menu.

[0039] (23) MenuId: A unique identifier field for menu items, used to identify specific menu items in the configuration, filtering and rendering stages.

[0040] (24) RoleMenuItem: Represents an enumeration or constant set of menu items for role management, such as InviteMic (invite to mic), KickOutRoom (kick out of room), etc.

[0041] (25) isHasRightControl: The permission judgment interface provided by the server, which returns a boolean value (true / false) indicating whether the current operator has control permissions for a specific operation.

[0042] (26) initFilterData: A method in MenuFilter used to initialize filter context data (such as operator role level, operated user role level, server permission set, etc.).

[0043] (27) filterMenu: The core method in MenuFilter that executes the menu item filtering logic, receives the menu configuration items and returns the filtering results.

[0044] (28) sigShowMenu: A signal sent by VoiceLiveInterface to MenuManager, carrying menu configuration, pop-up position and context data, used to trigger the menu display process.

[0045] (29) generateMenu: A method in MenuManager to generate the actual QMenu control based on the filtered menu configuration.

[0046] (30) VoiceLiveInterface: Voice live interface component, which is the UI component in the client responsible for displaying the voice room interface. It is used to respond to the user's right-click operation and send a menu display signal to MenuManager.

[0047] (31) appPos: The screen global coordinates of the upper left corner of the main window, which serves as the reference point for the pop-up position adaptive algorithm.

[0048] (32) isOverRight: A status flag in the position adaptation module used to mark whether the menu has been horizontally flipped to the left.

[0049] (33) Idle / Loading / Ready / Rendering / Displaying: The five state machine states of the menu management module, which correspond to waiting to be triggered, data loading, data ready, menu rendering, and menu display, respectively.

[0050] (34) onContextMenuRequested: The event callback function triggered when the client UI component responds to the user's right-click operation.

[0051] (35) myMaxRoleLevel: The highest role level value that the operator has in the current space or room, used to compare with the role level of the operated user.

[0052] As one optional application scenario of this disclosure embodiment, such as Figure 1 As shown, application 101 is installed in terminal device 110, and user 130 can interact with application 101 through terminal device 110 and / or access device of terminal device 110.

[0053] For example, application 101 can be any application that needs to provide users with an entry point for operations on interface objects, such as social applications, collaboration applications, management applications, etc. Figure 1 In the application scenario shown, if application 101 is active, terminal device 110 can display the interface 102 of application 101. The interface 102 may include various pages that application 101 can provide, such as object list pages, member management pages, channel management pages, etc. The interface displays various interactive target objects, and user 130 can trigger menu operations on the target objects to access the context menu associated with the object.

[0054] In some embodiments, terminal device 110 is communicatively connected to server 120 to provide services to application 101. Terminal device 110 may be a mobile terminal, fixed terminal, or portable terminal, etc., including but not limited to mobile phones, desktop computers, laptop computers, multimedia tablets, e-book devices, gaming devices, or any combination thereof, including accessories and peripherals of these devices or any combination thereof. In some embodiments, terminal device 110 may also support any type of interface, and server 120 may be various types of computing systems or servers capable of providing computing power, including but not limited to mainframes, edge computing nodes, computing devices in cloud environments, etc.

[0055] It should be noted that, Figure 1 This is merely an example of an application scenario and does not limit the scope of protection of this disclosure.

[0056] The embodiments of this disclosure will now be described with reference to the accompanying drawings. It should be understood that the pages shown in the drawings are merely examples, and various page designs are possible in practice. The various graphic elements on the page may have different arrangements and different visual representations, one or more elements may be omitted or replaced, and one or more other elements may also be present; no limitations are imposed on the embodiments described in this disclosure. Furthermore, the embodiments are primarily described below with reference to terminal device 110. It should be understood that the actions described relative to terminal device 110 can be performed by application 101 on terminal device 110, or can be performed by application 101 in conjunction with its server (e.g., server 120).

[0057] In related technologies, when users interact with different target objects, a fixed static menu configuration is often used. However, when users operate on specific objects, the menu items lack permission and real-time status linkage, the filtering mechanism is simple and crude, and invalid operation options or missing options are easily seen when the object's permissions or status change. This disclosure provides a method for generating a context menu, which can provide dynamic adaptation for target objects and accurately present valid operation options based on permissions and context status.

[0058] According to an embodiment of this disclosure, a method for generating a context menu is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0059] This embodiment provides a method for generating a context menu, which can be used in the aforementioned terminal devices, such as mobile phones, tablets, desktop computers, and other devices with related applications installed. Figure 2 This is a flowchart of a method for generating a context menu according to an embodiment of this disclosure, such as... Figure 2 As shown, the process includes the following steps: Step S201: In response to a menu trigger operation for a target object, obtain menu configuration data configured for the target object, as well as permission configuration data and context state data associated with the target object. The menu configuration data includes at least one initial menu item.

[0060] In this context, the target object refers to an interactive element in the interface that users can interact with by initiating menu-triggered actions. The type of target object can vary; for example, in social applications, the target object could be a user account, a channel, or a room; in file management applications, the target object could be a file or folder. Different types of target objects typically correspond to different operable scopes, therefore, corresponding menu data needs to be configured separately for each type of target object.

[0061] A menu-triggered action refers to an interactive behavior performed by a user on a target object within the interface to invoke a context menu, such as right-clicking or long-pressing the mouse. In response to this action, the terminal device triggers the subsequent menu generation process.

[0062] Menu configuration data is structured data pre-configured for a target object, describing the content of the object's context menu. It contains at least one initial menu item. Each initial menu item may contain fields describing the characteristics of that menu item, such as identification information, display text, and configuration attributes.

[0063] It's important to note that the menu configuration data is pre-configured. This means that the menu configuration data for each target object is determined before the menu trigger operation occurs. The terminal device can directly read this data when responding to the menu trigger operation, without needing to construct it on a temporary basis. This pre-configuration mechanism makes the definition of menu content independent of runtime rendering, facilitating unified management and maintenance.

[0064] Permission configuration data is data associated with a target object and reflects the permissions that the current operator has for that target object. This data typically originates from the server and is used in the menu generation process to determine which menu items the current operator has the authority to execute. Permission configuration data can take various specific forms. For example, it can be role level data for the operator and the target object; it can be an authorization token issued by the server for the current session containing a specific operation code; or it can be bitmap data generated based on an access control list (ACL) that represents the operator's access permissions to various functional modules of the target object. This disclosure does not specifically limit this.

[0065] Context state data is local data reflecting the current state of the interface or business logic. Examples include the relationship between the target object and the operator (e.g., whether they are friends), the target object's current function on / off status (e.g., whether "Do Not Disturb" is enabled), the target object's online status, or the capacity status of its channel / space. This data can usually be obtained directly locally without requesting the server. By relying on this type of real-time local state data for menu item filtering (i.e., the second validation rule), it is possible to avoid menu item display delays or misjudgments caused by waiting for server responses or temporary data asynchrony between the server and client. This achieves highly real-time and accurate menu item filtering that is strictly synchronized with the current user interface and business logic state, thereby improving the accuracy of context menu display from the data source.

[0066] In response to the menu trigger operation, the terminal device obtains the above three types of data, providing a data foundation for subsequent menu item filtering and menu generation.

[0067] Step S202: Filter the initial menu items based on the verification rules to determine the set of menu items to be displayed; wherein, the verification rules include a first verification rule based on permission configuration data and a second verification rule based on context state data, and each initial menu item is configured to be associated with the first verification rule and / or the second verification rule.

[0068] Filtering refers to removing menu items that should not be displayed from multiple initial menu items in the menu configuration data according to validation rules, and retaining menu items that meet the conditions, thereby obtaining a set of menu items to be displayed, which is the set of menu items that will be rendered and displayed in the end.

[0069] The core of this step lies in the classification mechanism of the verification rules. Specifically, the verification rules include two categories: the first verification rule is based on permission configuration data to determine whether the current operator has the permission to execute the operation represented by the corresponding menu item; the second verification rule is based on context state data to determine whether the menu item should be displayed based on the current local business state.

[0070] The key is that each initial menu item is pre-configured to be associated with a first verification rule and / or a second verification rule. That is, during the menu configuration data definition phase, each initial menu item is explicitly specified as needing to be filtered by a particular verification rule. Specifically, an initial menu item can be associated only with the first verification rule, in which case filtering is based solely on permission configuration data; it can also be associated only with the second verification rule, in which case filtering is based solely on local context state data; or it can be associated with both types of rules simultaneously, in which case corresponding combined judgment logic must be satisfied. This allows verification logic from different sources to be independently assigned at the menu item level, thereby achieving precise management of menu item display control.

[0071] After filtering all initial menu items one by one, the menu items that pass the verification are aggregated into a set of menu items to be displayed.

[0072] Step S203: Generate and display a context menu for the target object based on the configuration attributes of each menu item in the set of menu items to be displayed.

[0073] Configuration attributes are the attribute information carried by each menu item in the menu configuration data, describing its display and interaction characteristics. These include visual attributes such as the display text, control type, and color of the menu item, as well as the associated operation logic.

[0074] In step S203, the terminal device traverses the set of menu items to be displayed determined in step S202, reads the configuration attributes of each menu item, renders the corresponding menu item according to the configuration attributes, and finally displays the generated context menu in the application interface for the user to perform corresponding operations on the target object.

[0075] It is worth noting that the menu items are generated based on their own configuration attributes, rather than being temporarily constructed during the rendering phase. This is consistent with the design concept of pre-configuring menu configuration data in step S201, further demonstrating the separation of menu content definition from runtime rendering.

[0076] In summary, the context menu generation method provided in this disclosure pre-configures menu configuration data for the target object and pre-configures the association between each initial menu item and validation rules within the menu configuration data, thereby achieving the classification and validation of menu items of different natures. As a result, the filtering logic for each menu item is independent and does not interfere with each other, accurately determining the set of menu items to be displayed. Furthermore, it generates and displays a context menu for the target object based on the configuration attributes of each menu item, avoiding the problem of inaccurate menu item display caused by mixed validation logic.

[0077] This embodiment provides a method for generating a context menu, which can be used in the aforementioned terminal devices, such as mobile phones, tablets, desktop computers, and other devices with related applications installed. Figure 3 This is a flowchart of a method for generating a context menu according to an embodiment of this disclosure, such as... Figure 3 As shown, the process includes the following steps: Step S301: In response to a menu trigger operation for a target object, obtain menu configuration data configured for the target object, as well as permission configuration data and context state data associated with the target object. The menu configuration data includes at least one initial menu item.

[0078] To ensure the real-time nature and accuracy of the data, especially since permission-related data is usually maintained by the backend authority, the process of obtaining permission configuration data associated with the target object can specifically include: responding to a menu-triggered operation for the target object by initiating an asynchronous data request to the server to obtain the permission configuration data associated with the target object.

[0079] Asynchronous data requests refer to the parallel execution of data requests and menu generation processes. Data requests are made in the background, and subsequent menu filtering and display processes are triggered only after the server returns the data, thus avoiding interface blocking caused by synchronous waiting. For example, after a user right-clicks on a target object, the terminal device immediately sends a data request to the server. While waiting for the server's response, a loading status can be displayed, and the menu content is fully presented once the data is ready, providing the user with timely visual feedback.

[0080] Furthermore, asynchronous data requests may fail in abnormal situations such as unstable network conditions or server response timeouts. In one optional implementation, if an asynchronous data request fails, the initial menu item configured to be associated with the first verification rule will be deemed to have failed verification. That is, when permission configuration data cannot be obtained normally from the server, all menu items that rely on server-side permission data for verification will be considered to not meet the display conditions and will not appear in the final generated context menu. This processing strategy effectively avoids the risk of unauthorized operations due to missing permission data, ensuring security in abnormal scenarios.

[0081] Step S302: Filter the initial menu items based on the verification rules to determine the set of menu items to be displayed; wherein, the verification rules include a first verification rule based on permission configuration data and a second verification rule based on context state data, and each initial menu item is configured to be associated with the first verification rule and / or the second verification rule.

[0082] Validation rules are the decision-making logic used to determine whether a given initial menu item should be displayed to the user in the current scenario. In this embodiment, validation rules are divided into two categories: the first validation rule is based on permission configuration data, and the second validation rule is based on context state data.

[0083] Each initial menu item is pre-configured to be associated with a first verification rule and / or a second verification rule. That is, during the definition phase of the menu configuration data, each initial menu item has been explicitly specified as to which type of verification rule it should be filtered by, so that the verification logic from different sources can be independently assigned at the menu item level.

[0084] The first verification rule, based on permission configuration data, determines whether the operator has the necessary permissions for the operations corresponding to the initial menu items associated with the first verification rule. Operation permissions refer to the operator's qualification to perform a specific operation within the current application environment, such as whether they have the right to delete a channel or adjust other users' roles. The first verification rule reads the authorization information related to the operator and the target object from the permission configuration data, compares the permissions of each initial menu item one by one, and only retains the menu items for which the operator has the necessary permissions in the set to be displayed.

[0085] In some optional implementations, the permission configuration data includes at least the operator's role level data and the target object's role level data. Role level data is a quantitative description of the permission level of the operator or target object in the current application system, usually represented by a numerical value or an enumeration, such as ordinary member, administrator, super administrator, etc.

[0086] At this point, the execution process of the first verification rule is as follows: First, the operator's role level data is compared with the target object's role level data to obtain the first comparison result; then, based on the first comparison result and the preset permission verification rule, it is determined whether the operator has the operation permission, thereby determining whether the initial menu item configured to be associated with the first verification rule passes the verification.

[0087] Specifically, role level data describes the user's permission level in the current space or room. The higher the role level, the more management operations can be performed. Comparison refers to comparing the values ​​of two role levels according to preset rules.

[0088] For example, for the "Kick Out of Room" menu item, the permission verification rules can stipulate that the menu item will only pass the first verification rule and be retained in the set of menu items to be displayed if the operator's role level is higher than the target object's role level; otherwise, if the operator's level is not higher than the target object's level, the menu item will be filtered out and removed. Furthermore, the first comparison result can be combined with the permission control interface result returned by the server to comprehensively determine the operator's permission for the operation represented by the menu item, further improving the accuracy of the verification. By introducing dual verification of role level comparison and server-side permission data, it is possible to effectively prevent low-privilege users from performing management operations beyond their authorized scope.

[0089] The second verification rule, based on contextual state data, determines whether the initial menu item associated with the second verification rule meets the display conditions. Display conditions refer to the prerequisites that a menu item must meet at the local state level to be presented to the user, such as whether the target object is currently in a specific state or whether there is a relationship between the operator and the target object. Unlike the first verification rule, which relies on server-side permission data, the second verification rule only relies on state information obtainable locally by the terminal device, without initiating network requests, thus resulting in lower latency and higher execution efficiency.

[0090] In some optional implementations, the context state data includes at least the relationship state between the target object and the operator, and the current function on / off state of the target object. The relationship state refers to the application-level association between the operator and the target object, such as whether the operator and the target user have established a friend relationship; the function on / off state refers to whether the target object currently has a specific function enabled, such as whether the message do-not-disturb function is enabled.

[0091] At this point, the execution process of the second verification rule is as follows: compare the relationship status or function switch status with the preset display conditions of the corresponding menu item to obtain the second comparison result; based on the second comparison result, determine whether the corresponding menu item is displayed, thereby determining whether the initial menu item executing the second verification rule passes the verification.

[0092] Specifically, relationship status is state data describing the business relationship between the target object and the operator, such as whether the target object has established a friend relationship with the operator; function switch status is Boolean data describing whether a certain function of the target object is currently on or off, such as whether the target object has currently enabled the message do-not-disturb function.

[0093] The preset display conditions are state judgment logics pre-specified for menu items during the configuration phase to determine whether they are displayed. For example, the preset display condition for the "Add Friend" menu item could be "The target object has not yet established a friend relationship with the operator." If the current relationship status does not meet this condition (i.e., they are already friends), the menu item is filtered out and removed. Similarly, the preset display condition for the "Turn on Do Not Disturb" menu item could be "The target object has not currently turned on the Do Not Disturb function." If the function is already turned on, "Turn off Do Not Disturb" is displayed instead of "Turn on Do Not Disturb." The second verification rule relies only on locally available state data for judgment, without requesting the server, allowing the filtering of these menu items to be completed efficiently locally.

[0094] In this embodiment, each initial menu item is pre-assigned an association with a validation rule during the configuration phase. This association can include the following scenarios: Menu items are only associated with the first verification rule, which means that the menu item is verified through server-side permission data.

[0095] The menu item is only associated with the second verification rule, which means that the menu item is verified using local context state data.

[0096] Menu items are associated with both the first and second verification rules, meaning they can only be displayed if both server-side permission verification and local logic verification are satisfied.

[0097] In a preferred embodiment, each initial menu item is configured to be associated with only one of the first verification rule and the second verification rule, that is, server-side permission verification and local logic verification are mutually exclusive for each menu item.

[0098] Specifically, during the development phase, each menu item is pre-assigned to either a server-side verification category or a local logic verification category. Menu items assigned to a server-side verification category (such as "ban room", "kick out channel", etc., which involve access control) are only associated with the first verification rule. The verification is determined based on the comparison between the operator's role level and the operator's role level. Menu items classified as local logic verification categories (such as "Add Friend" and "Read Mark" which can be directly determined by local status) are only associated with the second verification rule. The display condition is determined based on the relationship between the target object and the operator or the function switch status.

[0099] In this preferred embodiment, the two types of verification are executed mutually exclusively, which avoids making unnecessary server requests for matters that can be judged locally, and also ensures that operation items involving permission control are subject to unified authorization management by the server.

[0100] In another implementation, some menu items can be configured to be associated with both the first and second verification rules simultaneously. In this case, server-side permission verification is performed first, followed by local logic verification. Only when both verifications pass is the menu item included in the set of menu items to be displayed. For example, for an operation item that requires both "the operator has management privileges" (server-side verification) and "the target user is not currently in the blacklist" (local status verification), this dual association configuration method can be used to achieve more granular display control.

[0101] After filtering all initial menu items one by one, the menu items that pass the verification are aggregated into a set of menu items to be displayed. This set is the actual basis for subsequent menu generation and rendering.

[0102] Step S303: Generate and display a context menu for the target object based on the configuration attributes of each menu item in the set of menu items to be displayed.

[0103] Regarding the generation of menu items, to meet the needs of different interaction scenarios, in one optional implementation, the configuration properties of each menu item include a control type property. Based on the control type property corresponding to each menu item, the corresponding interactive control is generated, and the context menu containing the interactive control is rendered and displayed.

[0104] Interactive controls are UI elements embedded in context menus that users can directly interact with. Their types can include the following: Text controls are the most basic form of menu items, presenting operation options in text form. They can be further supported by custom colors, such as displaying warning text (like "delete") in red to enhance visual differentiation.

[0105] Button controls are used to trigger immediate action commands, such as "Send Now" or "Confirm Delete".

[0106] A checkbox is a selectable menu item used to indicate an independently toggled function state, such as "Do not listen to this user's voice". Users can check or uncheck the box, and each operation inverts the current state.

[0107] A radio button is a set of mutually exclusive menu items. Only one item in the group can be selected at any given time. It is suitable for scenarios where multiple items can be selected at once, such as selecting the duration of message do-not-disturb (options such as "15 minutes", "1 hour", and "permanent" are mutually exclusive).

[0108] A slider control is a menu item that allows users to input continuous values ​​by dragging a slider. It is suitable for scenarios that require fine-tuning of values, such as volume control. The slider control sets a minimum value, a maximum value, and a current value, and binds a callback function for value changes. When the user drags the slider, the corresponding business logic is triggered in real time.

[0109] Progress bar controls are used to visually display the progress of a task or status, such as file upload progress.

[0110] By supporting multiple control types, context menus can configure the most suitable interactive interface for different types of operations. For example, checkbox controls can clearly and unambiguously display the on / off state of a function, avoiding user misunderstanding of the current state; radio button controls ensure the uniqueness of selection among multiple mutually exclusive options, preventing conflicting settings; and slider controls allow users to make continuous and fine-grained numerical adjustments, avoiding the inconvenience and numerical errors caused by multiple clicks or text input. This mechanism of "precise matching of control type and operation intent" allows users to accurately and efficiently understand and set the operations and states represented by menu items, thereby further ensuring the accuracy of menu function execution and faithful reflection of user intent at the interaction level, and improving the overall reliability of the operation.

[0111] Step S304: Determine the pop-up location of the context menu.

[0112] Regarding the display of the menu, to ensure that the context menu is always fully displayed within the visible range of the application interface and to prevent it from being truncated or obscured beyond the window boundaries, the pop-up position of the context menu is determined, specifically including: Obtain the boundary range of the main window of the graphical user interface, the size information of the context menu, and the current position information of the menu trigger operation; determine the target pop-up position of the context menu based on the boundary range, size information, and current position information; display the context menu at the target pop-up position.

[0113] Regarding the specific method for determining the target pop-up position, the initial pop-up area of ​​the context menu can be calculated based on the current position and size information, which is the rectangular area occupied by the menu under the default pop-up strategy (the default strategy is usually: the left edge of the menu is aligned with the trigger position, and the top edge of the menu is aligned with the trigger position, i.e., displayed to the right and down). If the initial pop-up area exceeds the boundary range, the initial pop-up area is flipped and adjusted horizontally and / or vertically to obtain the target pop-up position.

[0114] Regarding the specific rules for flipping and adjusting, one optional implementation includes the following two: First, if the right boundary of the initial pop-up area exceeds the right boundary of the boundary range, the pop-up direction of the context menu is flipped to the left, and a preset pixel spacing is reserved on the left side of the initial pop-up area so that the right edge of the menu is roughly aligned with the trigger position, while maintaining a certain gap between the menu and the trigger position to avoid the menu from overlapping with the trigger point; Second, if the lower boundary of the initial pop-up area exceeds the lower boundary of the boundary range, the pop-up direction of the context menu is flipped upward so that the bottom edge of the menu is roughly aligned with the trigger position.

[0115] Based on the above flipping rules, further edge issues that may occur after flipping can be addressed. Specifically, if the context menu pop-up direction flips upwards but not to the left, the target pop-up position is shifted to the right by a preset pixel spacing in the horizontal direction to avoid visual obstruction between the menu and the trigger point (such as the mouse cursor). If the upper boundary of the target pop-up area determined after the upward flip still exceeds the upper boundary of the boundary range (i.e., the menu height exceeds the distance between the trigger position and the upper boundary of the window), top alignment is performed based on the upper boundary of the graphical user interface, forcibly fixing the top of the menu to the upper boundary of the window to ensure that the menu does not exceed the visible area in the vertical direction.

[0116] The aforementioned multi-layered pop-up position adaptive calculation algorithm, which includes horizontal flip judgment, vertical flip judgment, pixel spacing reservation, and top alignment forced processing, covers and solves all possible boundary overflow situations that may occur in the menu under mainstream window sizes and screen positions. This ensures that the menu rendering engine can calculate the effective display coordinates within the visible area through a defined logical process at any trigger position (including near the four corners and edges of the window) and under different window sizes. This greatly improves the robustness, environmental adaptability, and calculation reliability of the context menu display function, and fundamentally avoids menu display abnormalities or functional unavailability caused by position calculation failures.

[0117] In summary, the context menu generation method provided in this disclosure firstly pre-configures the association relationship between each initial menu item and the verification rules, and synchronously obtains permission configuration data and context state data when the menu is triggered, providing a sufficient and clearly categorized data foundation for subsequent filtering; on this basis, an asynchronous data request mechanism is introduced to obtain permission configuration data, so that the terminal device does not need to suspend the main process during network request, ensuring the response efficiency of the menu pop-up; at the same time, for abnormal scenarios where asynchronous requests fail, menu items that depend on server-side permission data are uniformly judged as failing verification, preventing the presentation of unauthorized menu items to users due to data loss, and ensuring operational security. Secondly, by dividing the verification rules into a first verification rule based on permission configuration data and a second verification rule based on context state data, and by explicitly specifying the verification rule type associated with each initial menu item at the menu configuration level in advance, verification logic from different sources can be independently assigned at the menu item level. A role level comparison mechanism is introduced in the first verification rule, which can accurately reflect the actual authorization scope of the operator to the target object. A local comparison mechanism of relationship state and function switch state is introduced in the second verification rule, which can efficiently determine whether each menu item meets the display conditions of the current context. The two are independent of each other and each performs its own function, jointly ensuring the accuracy and consistency of the filtering results.

[0118] Furthermore, by supporting various types of interactive controls such as text controls, button controls, checkboxes, radio buttons, progress bars, and sliders, the context menu can carry complex interactive functions such as numerical adjustment and state switching within a single interface level, significantly expanding the application scenarios and interactive capabilities of the context menu. Meanwhile, by comprehensively considering the main window boundary range, the context menu size, and the current position of the menu trigger operation, the target pop-up position is pre-calculated before display. Horizontal and vertical boundary overflows are adjusted by flipping, supplemented by pixel spacing reservations and top alignment, ensuring that the context menu is fully displayed within the main window's visible area under various trigger positions. This effectively avoids the problem of menu content being obscured or exceeding screen boundaries, improving the user experience.

[0119] To better illustrate the method for generating context menus according to embodiments of this disclosure, a preferred embodiment will be provided below. This embodiment is intended to detail the implementation process of this disclosure, but is not intended to limit the scope of protection of this disclosure.

[0120] In voice-based social desktop clients, users frequently need to perform management operations on various objects such as spaces, channels, and members. The context menu is the core interaction method that serves as the entry point for these operations. However, traditional implementations generally have the following limitations: menu content is hard-coded and scattered across various UI components, making it difficult to maintain and extend in a unified manner; the validation logic for menu items uses a mixed single judgment method, failing to separate validation based on server-side permission data from validation based on local state, leading to interference between menu items of different natures and inaccurate display control; menus only support text buttons, failing to meet complex interaction needs such as volume adjustment and message do-not-disturb mode; when the menu pops up, the data has not yet been fully loaded, requiring users to wait to obtain the complete menu content; and the menu pop-up position lacks boundary processing, potentially exceeding the visible area of ​​the window.

[0121] To address the aforementioned issues, this disclosure provides a method for generating context menus. The following detailed explanation uses a voice-based social client implemented using PyQt5 (a Python graphical user interface development framework) as a specific preferred example.

[0122] This summary embodiment provides a right-click menu management system for a voice-based social client based on the PyQt5 framework. Figure 4 This is a schematic diagram of the system architecture, such as... Figure 4 As shown, the entire system runs within the voice-based social client and adopts a layered architecture design that separates configuration and rendering. The top-level entry point of the system is MenuHelper (menu configuration module), which connects downwards to MenuManager (menu management module). MenuManager, as the core scheduling hub, coordinates the following six sub-modules: MenuFilter (permission filtering module), ActionFunction (control encapsulation module), MenuRoleObject (role management module), MenuVoiceChannelObject (channel scheduling module), MenuPositionAdapter (position adaptation module), and Requester (data request module).

[0123] The ActionFunction module is responsible for creating various QWidgetAction instances (custom control menu item action classes) and outputting control instances for menu rendering. MenuRoleObject interfaces with room role data, supporting the dynamic generation of role management menus. MenuVoiceChannelObject maintains a list of schedulable channels, supporting member scheduling scenarios. Requester accesses the server-side permission and status interfaces asynchronously, preloading data before the menu is displayed. Each module has a clear responsibility and well-defined boundaries, collectively supporting the complete operation of the context menu generation method.

[0124] In this preferred embodiment, the content of menu items is centrally configured and managed through MenuHelper, corresponding to the step of "obtaining pre-configured menu configuration data for the target object" in the context menu generation method. MenuHelper predefines menu configuration lists for different object types such as space, channel, and user. Each menu item is described by a structured dictionary, including configuration attributes such as MenuId (unique identifier of the menu item), display text, control type marker, and color, and supports nested sub-menu structures.

[0125] A typical menu configuration function, getUserMenuConfig() (a method for retrieving user menu configurations), can contain configurations for the following four types of menu items: The first type is simple text menu items, which can be directly specified in the configuration as menu identifiers in RoleMenuItem (a collection of menu items used to identify role management operations), such as InviteMic.

[0126] The second category is custom color menu items, where the text color is specified in the configuration through the ActionFunction.Color field. For example, the "Delete Friend" item can be configured as AlarmTextColor (alarm text color) to make it appear as red warning text, enhancing visual differentiation.

[0127] The third type is slider control menu items. Set ActionFunction.IsSlider (a flag field indicating whether it is a slider type) to True, and mark the item as needing to save the control reference using ActionFunction.IsNeedSaveBtn (a flag field indicating whether the control reference needs to be saved). This is suitable for scenarios that require continuous numerical input, such as volume adjustment (UserVolume, i.e., user volume control menu items).

[0128] The fourth category is checkbox control menu items. Setting ActionFunction.IsCheckBoxBtn (a marker field indicating whether it is a checkbox type) to True is suitable for function switch scenarios such as "Don't listen to this user's voice" (CloseListenUserVoice).

[0129] The above configurable design allows the business layer to declare "what menu items and their attributes are needed" without having to worry about the specific creation and rendering logic of the controls, thus achieving separation of menu content definition and runtime rendering.

[0130] Figure 5This is a schematic diagram of the execution flow of a right-click menu management system for a voice-based social client based on the PyQt5 framework, such as... Figure 5 As shown, the complete menu generation and display process goes through the following stages in sequence: First, the user triggers a right-click event, and the client responds with `onContextMenuRequested` (the callback function for the right-click menu request event). Then, `MenuFilter` initializes the filtering context, `MenuManager` generates an initial list of menu items based on the pre-configured menu data in `MenuHelper`, and calls `MenuFilter` to perform role-based permissions and local logic-based filtering to determine the set of menu items to be displayed. After filtering, `ActionFunction` renders the corresponding controls based on the configuration attributes of each menu item, `MenuPositionAdapter` calculates the target pop-up position of the menu, and finally, the menu is displayed on the interface for the user to select. When the user selects a menu item, the corresponding business logic is triggered, and the process ends.

[0131] Figure 6 This is a timing diagram illustrating the interactions between the various modules, such as... Figure 6 As shown, the complete message interaction process from the user's right-click to the final display of the menu is illustrated in detail: When a user right-clicks, MenuManager first sends a data preloading request to Requester (data request module); Requester asynchronously requests permission data, role information, and channel data from the server; after the server returns the data, Requester sends the data back to MenuManager via the done signal (data ready notification signal); MenuManager then calls MenuFilter's initFilterData() (initialize filter data method) to complete the filter context initialization, and then calls filterMenu (configuration item) (menu filter method) to perform category filtering. MenuFilter returns a list of filtered menu items; MenuManager then calls ActionFunction to create control instances of various QWidgetAction (custom control menu item action class); finally, it calls MenuPositionAdapter (position adaptation module) to calculate the target pop-up coordinates, and after obtaining the coordinates, displays the menu to the user. When the user clicks a menu item, the callback function is executed, completing the entire interaction loop.

[0132] In this embodiment, permission filtering is implemented by MenuFilter. Its core design is that each initial menu item is pre-configured to execute either a first validation rule or a second validation rule. This allows for the explicit division of two independent mapping tables during the development phase, ensuring that each menu item belongs to a unique category and does not overlap with others. Specifically: The `roleMenu` (server-side permission mapping table) includes all menu items that require permission checks via the server-side permission interface, such as `CreateChannel`, `DeleteChannel`, `EditChannel`, `EditTeamStructure`, `InviteMic`, `KickOutRoom`, `SilenceUser`, and `AddRoomBlackList`. Whether these menu items are displayed depends on the comparison between the operator's role level and the target user's role level, as well as the return value of the server's `isHasRightControl` (permission control interface, returning a boolean value indicating whether the operator has the necessary permissions for that operation).

[0133] The `localLogicMenu` (local logic judgment mapping table) includes all menu items that can be directly judged through local data, such as status-based menu items like `LeaveMic` (mute), `RoomMsgNotDisturb` (do not disturb room messages), `RoomMsgDisturb` (cancel do not disturb room messages), `RoomMarkHasRead` (mark room as read), `TopRoom` (pinned room), `UnTopRoom` (cancel pinned room), `ChannelMsgNotDisturb` (do not disturb channel messages), `ChannelMarkHasRead` (mark channel as read), and `LeaveRoom` (leave room). The display of these menu items depends solely on the local business status, without requiring server requests, and can be efficiently judged locally.

[0134] The two mapping tables can be clearly defined during the development phase, ensuring that each menu item belongs to a unique category. During filtering, each table independently calls its corresponding validation function without interfering with the others. This mutually exclusive classification design ensures that menu items of different natures follow their respective appropriate validation channels, resulting in accurate and controllable filtering results.

[0135] The complete configuration and filtering process includes: UI components (such as VoiceLiveInterface, the voice live streaming interface component) pass configuration data to MenuManager via the sigShowMenu(menuConfig, pos, data) signal (a menu display signal carrying menu configuration data, pop-up position, and context data) after being triggered by a right-click. MenuManager calls MenuFilter's filterMenu(menuConfig, data) (menu filtering method, receiving menu configuration items and context data) to perform permission checks (for roleMenu class menu items) and local logic checks (for localLogicMenu class menu items) in sequence. MenuFilter returns a list of filtered menu items. MenuManager calls generateMenu(menuConfig) (menu generation method) to complete rendering, creating and displaying the final menu through QMenu (context menu control class). When the user clicks a menu item, the corresponding callback function is executed, and the result is fed back to the UI component, completing the operation loop.

[0136] This disclosure further maintains the unified encapsulation of multiple control types. Specifically, ActionFunction (control encapsulation module) uniformly encapsulates the creation logic of various QWidgetAction (custom control action classes), as follows: getColorfulTextAction: Creates menu items with custom colored text, suitable for warning or emphasis actions that require visual differentiation, such as displaying "Delete Friend" in red text to visually highlight high-risk actions.

[0137] `getSliderAction` (get slider action): Creates a menu item embedded in a QSlider (slider control), sets the minimum, maximum, and current values, and binds a callback function for value changes. The corresponding business logic is triggered in real-time when the user drags the slider. Suitable for scenarios requiring fine-tuning of continuous values, such as volume control (UserVolume).

[0138] getCheckBoxBtnAction (Get Checkbox Button Action): Creates a menu item with a QCheckBox (a checkbox control that can be checked or dechecked independently). It is suitable for independent on / off functions, such as "CloseListenUserVoice", which mutes the user when checked.

[0139] getRadioBtnAction (Get Radio Button Action): Creates a menu item with a QRadioButton (radio button control, mutually exclusive selection within the same group), suitable for multiple selection scenarios, such as selecting the duration of message do-not-disturb ("15 minutes", "1 hour", "permanent", etc. are mutually exclusive).

[0140] Through unified encapsulation, the creation details of various controls are transparent to upper-level callers. MenuManager only needs to call the corresponding method based on the configuration properties of the menu item to obtain the control instance, which further strengthens the separation between configuration definition and control rendering.

[0141] This disclosure also includes role management and channel scheduling, as detailed below: MenuRoleObject (role management module) is specifically designed to handle role-based menus within a room or space. This module dynamically retrieves the current room's role list from the server and compares the operator's myMaxRoleLevel (the operator's highest role level, i.e., the highest permission level the operator holds in the current space) with each role's level. It automatically sets the operable status of the corresponding role's menu items, allowing the menu item to be clicked only when the operator's level is higher than the target role's; otherwise, it is grayed out and disabled. This provides a visual representation of role level verification at the rendering level.

[0142] MenuVoiceChannelObject (channel scheduling module) is specifically designed for batch scheduling scenarios of members. It uses QListWidget (a list control used to display a scrollable list of items) to display the list of currently schedulable target channels. When displaying, it checks the current capacity of each channel. If a channel is full, it marks the corresponding list item as disabled and adds a prompt to prevent users from scheduling members to full channels, thus improving the effectiveness and accuracy of the operation.

[0143] The embodiments disclosed herein also include asynchronous data preloading and state machine transitions. Figure 7 This is a schematic diagram of the state machine of the menu management module, such as... Figure 7 As shown, the menu management module undergoes an orderly transition through five states throughout its entire lifecycle, as detailed below: The system initially operates in the Idle state (waiting for a right-click event to trigger). After a user triggers a right-click, the Requester initiates an asynchronous server request, and the system enters the Loading state (retrieving server permissions, roles, mute status, etc.). Once the server returns data or the request times out, the system transitions to the Ready state (all necessary data for filtering is ready). The MenuManager then generates the menu and renders controls, entering the Rendering state (generating various interactive controls and building the menu structure). After the menu is rendered and presented to the user, it enters the Displaying state (displaying the menu and awaiting user interaction). When the user completes their action or the menu is closed, the system returns to the Idle state, waiting for the next trigger.

[0144] The beneficial effect of this asynchronous preloading mechanism is that the permission data, role data, mute status, etc. required when the menu pops up are all loaded in the Loading stage, so that users can get the complete and accurate menu content the moment they see the menu, without having to wait a second time.

[0145] This disclosure also includes adaptive calculation of the menu pop-up position, as detailed below: MenuPositionAdapter (position adaptation module) uses the screen-wide coordinates appPos (Application Position, the coordinates of the top-left corner of the main window, used as the reference point for boundary judgment) and the available bounding rectangle determined by the width and height of the main window as a basis to calculate the target pop-up coordinates of the menu according to the following steps: Horizontal (X-axis) adjustment: The default is to display the menu to the right, with the left edge aligned with the mouse trigger point. If "current mouse X coordinate + menu width > main window right boundary X coordinate", meaning the menu would extend beyond the right edge of the window when displayed to the right, then switch to displaying it to the left: adjust the menu X coordinate to "mouse X coordinate - menu width - 8 pixels" (leaving an 8-pixel gap to prevent the menu from being too close to the trigger point), and set isOverRight (the right overflow flag used to record whether a horizontal flip has occurred) to True.

[0146] Vertical (Y-axis) adjustment: The default is to display the menu downwards, with the top edge aligned with the mouse trigger position. If "current mouse Y-coordinate + menu height > main window bottom boundary Y-coordinate", meaning the menu would exceed the window's bottom boundary when displayed downwards, then switch to displaying it upwards: adjust the menu's Y-coordinate to "mouse Y-coordinate - menu height", so that the bottom of the menu is roughly aligned with the mouse position.

[0147] Top boundary overflow prevention: If the new Y coordinate after flipping upwards is still less than the Y coordinate of the top boundary of the main window (i.e., the menu height exceeds the distance between the trigger position and the top boundary of the window), the Y coordinate will be forcibly set to the Y coordinate of the top boundary of the main window. That is, the top alignment is based on the top boundary of the window to ensure that the menu does not exceed the visible area.

[0148] Horizontal fine-tuning after flipping: If a vertical flip occurs (menu is displayed upwards) and no horizontal flip occurs (isOverRight is False, meaning the menu is still displayed to the right of the mouse), the X coordinate will be shifted an additional 8 pixels to the right to prevent the first menu item from being visually obscured by the mouse cursor.

[0149] This adaptive calculation method fully covers various combinations of scenarios, such as the menu exceeding the right boundary, exceeding the downward boundary, exceeding the right and downward boundaries simultaneously, and exceeding the upper boundary again after flipping upwards, ensuring that the context menu can be fully displayed in the visible area of ​​the main window at any mouse trigger position.

[0150] Taking the example of a user right-clicking on a target member in a member list in a voice-based social networking client, the complete process of this embodiment is as follows: When a user right-clicks a target member in the member list, the `onContextMenuRequested` event (right-click menu request callback) is triggered. The `MenuManager` calls the `Requester` to asynchronously request the target member's role level, muted status, and list of schedulable channels from the server. After the data is returned, the `Requester` sends a `done` signal to the `MenuManager`. The `MenuManager` calls the `initFilterData()` method of the `MenuFilter`, passing in the operator's `myMaxRoleLevel`, the target member's role level, and the server's permission set to complete the filter context initialization. The `MenuManager` iterates through the user's menu configuration in the `MenuHelper`, calling `filterMenu()` to filter each initial menu item. The `roleMenu` class of menu items (such as `InviteMic` to invite users to speak and `KickOutRoom` to kick users out of the room) determines whether to retain them based on the `isHasRightControl` interface result and a comparison with the user's role level. The `localLogicMenu` class of menu items (such as `LeaveMic` to leave the microphone and `TopRoom` to pin a room) determines whether to retain them based on a local state validation function. The `MenuManager` calls the `ActionFunction` to create corresponding `QWidgetAction` control instances for each filtered menu item. The `MenuPositionAdapter` calculates the target pop-up coordinates based on the mouse coordinates and the window boundaries. Finally, a `QMenu` is generated and displayed at the target pop-up position. When the user clicks on it, the corresponding slot function (callback function) is triggered to execute the business logic, and the complete operation loop ends.

[0151] Furthermore, the system of this disclosure embodiment also supports expansion to scenarios such as online meetings: by adding menu item configurations such as "camera control" and "screen sharing authorization" to MenuHelper, adding corresponding local logic judgment functions to MenuFilter, extending the preloading of participant device status in Requester, and replacing MenuVoiceChannelObject (channel scheduling module) with the "meeting group" component, the same menu management architecture can be reused to more business scenarios, demonstrating good scalability.

[0152] In summary, this embodiment of the present disclosure, through its architecture design that separates configuration and rendering, decouples the centralized configuration of menu content from runtime control rendering. Combined with a classification-based mutual exclusion filtering mechanism implemented using two independent mapping tables, roleMenu and localLogicMenu (server-side permission judgment and local logic judgment), it ensures that each menu item follows its own appropriate validation channel based on its nature, achieving precise control over menu item display. Through the unified encapsulation of various QWidgetAction control types using ActionFunction, complex interactive controls such as sliders, checkboxes, and radio buttons can be seamlessly embedded into the context menu, significantly expanding the menu's functional expressive capabilities. The asynchronous preloading and ordered state machine transitions of the Requester module ensure that permission and state data are ready immediately when the menu pops up, eliminating user waiting time. Finally, the multi-directional adaptive position algorithm of MenuPositionAdapter ensures that the menu is fully displayed within the main window's visible area regardless of the trigger position, comprehensively improving the user's operating experience in voice-based social scenarios.

[0153] This embodiment also provides a context menu generation device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0154] This embodiment provides a context menu generation device, such as... Figure 8 As shown, it includes: The acquisition module 801 is used to acquire, in response to a menu trigger operation for a target object, menu configuration data configured for the target object, as well as permission configuration data and context state data associated with the target object. The menu configuration data includes at least one initial menu item. The filtering module 802 is used to filter the initial menu items based on the verification rules to determine the set of menu items to be displayed; wherein, the verification rules include a first verification rule based on permission configuration data and a second verification rule based on context state data, and each initial menu item is configured to be associated with the first verification rule and / or the second verification rule; The generation module 803 is used to generate and display a context menu for a target object based on the configuration attributes of each menu item in the set of menu items to be displayed.

[0155] In some alternative implementations, the acquisition module 801 is used for: In response to a menu-triggered action targeting a target object, an asynchronous data request is sent to the server to obtain the permission configuration data associated with the target object.

[0156] In some alternative implementations, the filtering module 802 is further configured to: If the asynchronous data request fails, the initial menu item that will be configured to be associated with the first verification rule will be judged as failing the verification.

[0157] In some alternative implementations, the filtering module 802 is used for: Based on the permission configuration data, determine whether the operator has the permission to perform the operation corresponding to the initial menu item associated with the first verification rule.

[0158] In some optional implementations, the permission configuration data includes at least the operator's role level data and the target object's role level data; the filtering module 802 is used for: The operator's role level data is compared with the target object's role level data to obtain the first comparison result; Based on the first comparison result and the preset permission verification rules, it is determined whether the operator has the operation permission, thereby determining whether the initial menu item configured to be associated with the first verification rule passes the verification.

[0159] In some alternative implementations, the filtering module 802 is used for: Based on the context state data, determine whether the initial menu item associated with the second verification rule meets the display conditions.

[0160] In some optional implementations, the context state data includes at least the relationship state between the target object and the operator, and the current function on / off state of the target object; the filtering module 802 is used for: The relationship status or function switch status is compared with the preset display conditions of the corresponding menu item to obtain the second comparison result; Based on the second comparison result, it is determined whether the corresponding menu item is displayed, thereby determining whether the initial menu item configured to be associated with the second verification rule passes the verification.

[0161] In some optional implementations, the configuration properties of each menu item include a control type property; the generation module 803 is used for: Based on the control type attribute of each menu item, generate the corresponding interactive control; the interactive control includes at least one of text control, checkbox control, radio button control and slider control; The rendering displays a context menu for the target object, containing interactive controls.

[0162] In some alternative implementations, the generation module 803 is used for: Obtain the boundary range of the main window of the graphical user interface, the size information of the context menu, and the current position information of the menu trigger operation; Determine the target pop-up location of the context menu based on the boundary range, size information, and current location information; Display a context menu at the target pop-up location.

[0163] In some alternative implementations, the generation module 803 is used for: Calculate the initial pop-up area of ​​the context menu based on the current position and size information; If the initial pop-up area exceeds the boundary range, the initial pop-up area will be flipped and adjusted horizontally and / or vertically to obtain the target pop-up position.

[0164] In some alternative implementations, the generation module 803 is used for: If the right edge of the initial pop-up area exceeds the right edge of the boundary range, the pop-up direction of the context menu will be flipped to the left, and a preset pixel spacing will be reserved on the left side of the initial pop-up area. If the lower boundary of the initial pop-up area exceeds the lower boundary of the boundary range, the pop-up direction of the context menu will be flipped upwards.

[0165] In some alternative implementations, the generation module 803 is further configured to: If the context menu pop-up direction flips upwards but not to the left, the target pop-up position will be shifted to the right horizontally by a preset pixel spacing. If the upper boundary of the target pop-up area determined after flipping upwards exceeds the upper boundary of the boundary range, then top alignment is performed based on the upper boundary of the graphical user interface.

[0166] The context menu generation apparatus provided in this disclosure can execute the context menu generation method provided in any embodiment of this disclosure, and has the corresponding functional modules and beneficial effects of the method execution. Further functional descriptions of the various modules and units described above are the same as in the corresponding embodiments described above, and will not be repeated here.

[0167] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure.

[0168] The following is a detailed reference. Figure 9The diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present disclosure. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 901, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 902 or a program loaded from memory 908 into random access memory (RAM) 903. The RAM 903 also stores various programs and data required for the operation of the electronic device. The processor 901, ROM 902, and RAM 903 are interconnected via a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0169] Typically, the following devices can be connected to I / O interface 905: input devices 906 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 907 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 908 including, for example, magnetic tapes, hard disks, etc.; and communication devices 909. Communication device 909 allows electronic devices to exchange data via wireless or wired communication with other devices. Although Figure 9 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0170] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 909, or installed from a memory 908, or installed from a ROM 902. When the computer program is executed by the processor 901, it performs the functions defined in the context menu generation method of embodiments of this disclosure.

[0171] Figure 9 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0172] This disclosure also provides a computer-readable storage medium in which the methods described in this disclosure can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium after being downloaded over a network. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the context menu generation method shown in the above embodiments.

[0173] A portion of this disclosure can be applied to computer program products, such as computer program instructions, which, when executed by a computer, can invoke or provide methods and / or technical solutions according to this disclosure through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, and installation package files. Accordingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions; the computer compiling the instructions and then executing the corresponding compiled program; the computer reading and executing the instructions; or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0174] Although embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for generating a context menu, characterized in that, The method includes: In response to a menu trigger operation for a target object, obtain menu configuration data configured for the target object, as well as permission configuration data and context state data associated with the target object, wherein the menu configuration data includes at least one initial menu item; The initial menu items are filtered based on the verification rules to determine the set of menu items to be displayed; wherein, the verification rules include a first verification rule based on the permission configuration data and a second verification rule based on the context state data, and each initial menu item is configured to be associated with the first verification rule and / or the second verification rule; Based on the configuration attributes of each menu item in the set of menu items to be displayed, a context menu for the target object is generated and displayed.

2. The method according to claim 1, characterized in that, Obtaining permission configuration data associated with the target object, including: In response to a menu-triggered operation targeting the target object, an asynchronous data request is sent to the server to obtain permission configuration data associated with the target object.

3. The method according to claim 2, characterized in that, The method further includes: If the asynchronous data request fails, the initial menu item configured to be associated with the first verification rule will be judged as failing the verification.

4. The method according to claim 1, characterized in that, The first verification rule includes: based on the permission configuration data, determining whether the operator has the permission to perform the operation corresponding to the initial menu item associated with the first verification rule.

5. The method according to claim 4, characterized in that, The permission configuration data includes at least the operator's role level data and the target object's role level data; The first verification rule includes: The operator's role level data is compared with the target object's role level data to obtain a first comparison result; Based on the first comparison result and the preset permission verification rules, it is determined whether the operator has the operation permission, thereby determining whether the initial menu item configured to be associated with the first verification rule passes the verification.

6. The method according to claim 1, characterized in that, The second verification rule includes: determining whether the initial menu item associated with the second verification rule meets the display conditions based on the context state data.

7. The method according to claim 6, characterized in that, The context state data includes at least the relationship state between the target object and the operator, and the current function switch state of the target object; The second verification rule includes: The relationship state or the function switch state is compared with the preset display conditions of the corresponding menu item to obtain a second comparison result; Based on the second comparison result, it is determined whether the corresponding menu item is displayed, thereby determining whether the initial menu item configured to be associated with the second verification rule passes the verification.

8. The method according to claim 1, characterized in that, The configuration attributes of each menu item include control type attributes; generating and displaying a context menu for the target object based on the configuration attributes of each menu item in the set of menu items to be displayed includes: Based on the control type attribute of each menu item, generate corresponding interactive controls; the interactive controls include at least one of text controls, checkboxes, radio buttons, and sliders. The rendering displays a context menu for the target object that includes the interactive controls.

9. The method according to claim 1 or 8, characterized in that, The generation and display of the context menu for the target object includes: Obtain the boundary range of the main window of the graphical user interface, the size information of the context menu, and the current position information of the menu trigger operation; The target pop-up location of the context menu is determined based on the boundary range, the size information, and the current position information; The context menu is displayed at the target pop-up location.

10. The method according to claim 9, characterized in that, Determining the target pop-up location of the context menu based on the boundary range, the size information, and the current position information includes: Calculate the initial pop-up area of ​​the context menu based on the current position and the size information; If the initial pop-up area exceeds the boundary range, the initial pop-up area is flipped and adjusted horizontally and / or vertically to obtain the target pop-up position.

11. The method according to claim 10, characterized in that, The step of flipping and adjusting the initial pop-up area horizontally and / or vertically includes: If the right boundary of the initial pop-up area exceeds the right boundary of the boundary range, the pop-up direction of the context menu will be flipped to the left, and a preset pixel spacing will be reserved on the left side of the initial pop-up area. If the lower boundary of the initial pop-up area exceeds the lower boundary of the boundary range, the pop-up direction of the context menu will be flipped upwards.

12. The method according to claim 11, characterized in that, The method further includes: If the pop-up direction of the context menu flips upwards but does not flip to the left, the target pop-up position is shifted to the right by a preset pixel spacing in the horizontal direction. If the upper boundary of the target pop-up area determined after flipping upwards exceeds the upper boundary of the boundary range, then top alignment is performed based on the upper boundary of the graphical user interface.

13. A context menu generation apparatus, characterized in that, The device includes: The acquisition module is used to acquire, in response to a menu trigger operation for a target object, menu configuration data configured for the target object, as well as permission configuration data and context state data associated with the target object, wherein the menu configuration data includes at least one initial menu item; A filtering module is used to filter the initial menu items based on verification rules to determine a set of menu items to be displayed; wherein, the verification rules include a first verification rule based on the permission configuration data and a second verification rule based on the context state data, and each initial menu item is configured to be associated with the first verification rule and / or the second verification rule; The generation module is used to generate and display a context menu for the target object based on the configuration attributes of each menu item in the set of menu items to be displayed.

14. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory storing computer instructions, and the processor executing the computer instructions to perform the method for generating a context menu according to any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to perform the method for generating a context menu according to any one of claims 1 to 12.

16. A computer program product, characterized in that, Includes computer instructions for causing a computer to perform the method for generating a context menu according to any one of claims 1 to 12.

Images