CN118484191B - Graphical user interface generation method and device - Google Patents

Abstract

The application discloses a method and a device for generating a graphical user interface, which relate to the technical field of data processing and generate an initial protocol definition configuration file based on a protocol interface definition file; adding a data class label to a field in the initial protocol definition configuration file to generate a final protocol definition configuration file; acquiring a current interface layout file as an initial interface layout file; determining target positions of all data classes in an initial interface layout file and corresponding interface generation templates based on the data binding file; generating a corresponding control set by fields under each data class in the final protocol definition configuration file based on preset generation rules in the file of the interface generation template; and adding the control set to a corresponding target position in the initial interface layout file to form a final interface layout file. The method solves the problems of low development efficiency, high probability of manually introducing software faults and difficult flexible adjustment of interface layout and control patterns for different specific unmanned aerial vehicles.

Description

Graphical user interface generation method and device

Technical Field

The present application relates to the field of data processing technologies, and in particular, to a method and an apparatus for generating a graphical user interface.

Background

The unmanned aerial vehicle ground detection software is an indispensable part of unmanned aerial vehicle research and development process, and is responsible for carrying out real-time monitoring, state detection and parameter calibration on the unmanned aerial vehicle, so that the safety and stability of the unmanned aerial vehicle in the process of executing tasks are ensured. Such software typically includes three modules, a data parsing unit, a data display unit, and a data messaging encoding unit, wherein a Graphical User Interface (GUI) is used as a bridge for a user to interact with the software, and its development quality directly affects the user experience and the overall performance of the software. The main functions of the software include setting specific parameter combinations of the unmanned aerial vehicle, obtaining feedback information after setting, completing state detection of the unmanned aerial vehicle and calibrating parameters of specific flight tasks.

In the development of unmanned aerial vehicle ground detection software graphical user interfaces, two technical methods are mainly adopted at present. 1. Manually editing the interface layout file of the control combination writing: the developer manually composes a control combination in a visible and obtained mode by utilizing an interface development tool based on an interface definition document of the unmanned aerial vehicle ground detection protocol, and composes a corresponding interface layout file. 2. Dynamically creating a graphical user interface based on the configuration file: and the developer writes a configuration file according to the interface definition document to define the analysis mode and the display mode of the data. At run-time, the target program dynamically creates a graphical user interface from the configuration file content using a unified configuration parsing engine.

However, the development efficiency of the prior art is low, the probability of manually introducing software faults is high, and the problem that the interface layout and the control style are difficult to flexibly adjust for the requirements of different specific unmanned aerial vehicles exists.

Disclosure of Invention

In the embodiment of the application, by providing the graphical user interface generation method, the problems of low development efficiency, high probability of manually introducing software faults and difficulty in flexibly adjusting interface layout and control patterns for different specific unmanned aerial vehicles are solved.

In a first aspect, an embodiment of the present application provides a method for generating a graphical user interface, where the method includes: generating an initial protocol definition configuration file based on the protocol interface definition document; adding a data class label to a field in the initial protocol definition configuration file to generate a final protocol definition configuration file; wherein the data class corresponds to a sub-region in the graphical user interface; acquiring a current interface layout file as an initial interface layout file; determining target positions of all data types in the initial interface layout file and corresponding interface generation templates based on the data binding file; generating a corresponding control set by fields under each data class in the final protocol definition configuration file based on preset generation rules in the file of the interface generation template; and adding the control set to a corresponding target position in the initial interface layout file to form a final interface layout file.

In one possible implementation, the target location includes a corresponding initial interface layout file name and a parent control name for the displayed location.

In one possible implementation, the data binding file further includes a pre-generation operation policy that includes whether all children of the target parent control container are emptied.

In one possible implementation, the interface generation template includes a name including one or more control types and a parameter for determining a number of columns of the generation unit and a column in which each control type is located.

In one possible implementation, the generating the initial protocol definition configuration file based on the protocol interface definition document includes: reading a protocol interface definition document; identifying target data in the protocol interface definition document according to preset data definition, and converting the target data into data of a first data structure; formatting the data of the first data structure to generate an initial protocol definition configuration file.

In a possible implementation manner, the generating the corresponding control set based on the preset generation rule in the file of the interface generation template by the fields under each data class in the final protocol definition configuration file includes: reading the final protocol definition configuration file, and aggregating based on the data class labels; converting each data class after aggregation into a corresponding first multi-way tree; acquiring a preset generation rule of a corresponding data class from a file of the interface generation template; and generating a control tree corresponding to the corresponding first multi-tree based on the preset generation rule as a control set.

In one possible implementation manner, the adding the control set to the corresponding target position in the initial interface layout file forms a final interface layout file, including: generating an initial multi-way tree based on the initial interface layout file, generating corresponding access path identifiers for control container nodes in the interface layout file, and forming an association table of control names and corresponding access path identifiers, wherein each control container corresponds to one data class; acquiring a control name corresponding to the control tree; inquiring an access path identifier corresponding to the control name based on the association table; adding the control tree under a corresponding control container node of the initial multi-way tree based on the access path identifier to form a final multi-way tree; and generating a final interface layout file based on the final multi-way tree.

In one possible implementation, the data class label includes a high-to-low multi-layer class name.

In a second aspect, an embodiment of the present application provides a graphical user interface generating apparatus, including: the generating file module is used for generating an initial protocol definition configuration file based on the protocol interface definition file; the adding tag module is used for adding a data class tag to a field in the initial protocol definition configuration file to generate a final protocol definition configuration file, wherein the data class corresponds to a sub-area in a graphical user interface; the acquisition module is used for acquiring the current interface layout file as an initial interface layout file; the determining module is used for determining the target position of each data class in the initial interface layout file and the corresponding interface generating template based on the data binding file; the generation set module is used for generating a corresponding control set by fields under each data class in the final protocol definition configuration file based on a preset generation rule in the file of the interface generation template; and the adding position module is used for adding the control set to the corresponding target position in the initial interface layout file to form a final interface layout file.

In a fourth aspect, embodiments of the present application provide a computer-readable storage medium storing executable instructions that when executed by a computer enable the method of the first aspect or any one of the possible implementation manners of the first aspect.

One or more technical solutions provided in the embodiments of the present application at least have the following technical effects:

The embodiment of the application provides a graphical user interface generating method, which generates an initial protocol definition configuration file based on a protocol interface definition document, thereby remarkably improving the efficiency and accuracy of protocol definition and reducing the complexity and errors of manually writing the configuration file. By adding the data class label on the field of the protocol definition configuration file, the direct mapping of the data class and the graphic user interface subarea is realized. The mapping makes the interface design more visual, and is convenient for the developer to understand and maintain. The current interface layout file is obtained as an initial layout, and the target position of the data class in the interface is determined by combining the data binding file, so that the interface layout is more flexible. The developer can adjust the position of the data class according to the needs, and the developer can quickly adapt to different interface design requirements. And dynamically generating a corresponding control set according to the data class field in the final protocol definition configuration file and a preset generation rule in the file of the interface generation template. The dynamic generation mode enables the interface development to be more flexible, and can adapt to different data structures and display requirements. By automatically generating the interface layout file and the control set, the workload of a developer is reduced, and the development cost is reduced. Meanwhile, the link of manually writing codes is reduced, so that the possibility of errors is also reduced. The mapping relation between the data class and the graphic interface subarea is clear and definite, and the mechanism for dynamically generating the control is adopted, so that the whole system is easy to expand and maintain. When the protocol or interface changes, the new requirements can be quickly adapted only by updating the corresponding configuration file or template file. Through the automatically generated interface layout and control set, the consistency and the aesthetic property of the interface can be ensured, and the user experience is improved. Meanwhile, the control set is dynamically generated according to the data type field, so that the accuracy of data can be ensured. The development efficiency problem of manual editing of the graphical interface is solved, and the problem that software defects are easily introduced in manual editing of the graphical interface is avoided. In addition, compared with a method for directly controlling a target program to present a graphical user interface by using a text configuration file with DSL (English: domain Specific Language Chinese: domain-specific language) effect, the method can conveniently and flexibly adjust the interface layout and support various personalized customization controls.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are needed in the embodiments of the present application or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present application, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a flowchart of a graphical user interface generation method provided by an embodiment of the present application;

FIG. 2 is a flowchart illustrating an embodiment of generating an initial protocol definition configuration file based on a protocol interface definition document;

FIG. 3 is a specific flowchart of generating a corresponding control set based on a preset generation rule in a file of an interface generation template according to fields under each data class in a final protocol definition configuration file according to an embodiment of the present application;

FIG. 4 is a flowchart of adding a control set to a corresponding target location in an initial interface layout file to form a final interface layout file according to an embodiment of the present application;

FIG. 5 is a diagram illustrating a relationship between a data class and a graphical user interface according to an embodiment of the present application;

FIG. 6 is a schematic diagram of an initial interface layout without content according to an embodiment of the present application;

FIG. 7 is a schematic diagram of an initial interface layout with content according to an embodiment of the present application;

FIG. 8 is a schematic diagram of a possible content interface of an initial interface layout file according to an embodiment of the present application;

FIG. 9 is a schematic diagram of a tree structure corresponding to the content of an initial interface layout file according to an embodiment of the present application;

FIG. 10 is a schematic diagram of a tree structure for converting aggregated data classes into a corresponding first multi-tree according to an embodiment of the present application;

FIG. 11 is a schematic diagram of a tree structure of an initial interface layout file corresponding to a data class according to an embodiment of the present application;

FIG. 12 is a schematic diagram of merging an interface layout with a control tree according to an embodiment of the present application;

FIG. 13 is a schematic diagram of a first result of an interface generation provided by an embodiment of the present application;

FIG. 14 is a second result diagram of a generation interface provided by an embodiment of the present application;

FIG. 15 is a schematic diagram of a graphical user interface generating device according to an embodiment of the present application;

Fig. 16 is a schematic diagram of a gui generating server according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. It will be apparent that the described embodiments are some, but not all, embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

Some of the techniques involved in the embodiments of the present application are described below to aid understanding, and they should be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the application. Also, for the sake of clarity and conciseness, descriptions of well-known functions and constructions are omitted in the following description.

The ground detection data of the unmanned aerial vehicle system is usually combined by a plurality of data frames, wherein measurement information, state information, fault information and the like of the unmanned aerial vehicle airborne equipment are encoded into the detection data frames of the unmanned aerial vehicle and sent to the ground detection system according to a certain period. One of the main responsibilities of the ground detection system is to intuitively and accurately reflect the measurement data and the state of the unmanned aerial vehicle in the ground detection process. In the ground detection software development process, a data frame communication protocol document, commonly referred to as an interface definition document (ICD), is typically provided. The inspection data frames defined in the unmanned aerial vehicle interface definition document are typically composed of a plurality of data frames and a plurality of data fields within the frames. Because of the limitation of the maximum frame length, data and status of one device are typically scattered over multiple data frames. In the protocol frame configuration file, each field is associated with a data class label. The purpose of the data class label is to facilitate the aggregation of the associated fields to form a virtual data class.

The ground detection data of the unmanned aerial vehicle system relates to the transmission of a plurality of data frames, and the data frames contain various key information of unmanned aerial vehicle-mounted equipment, such as measurement data, state update, fault report and the like. The detailed data is encoded into a particular detected data frame and then transmitted to the ground detection system at predetermined periods. One of the core tasks of the ground detection system is to ensure that the real-time state and data change of the unmanned aerial vehicle in the ground detection flow can be accurately and intuitively reflected. In the development stage of the ground detection software, in order to ensure the correct transmission and parsing of data, a detailed data frame communication protocol document is usually provided, and this document is commonly called an interface definition document (ICD). In the interface definition document, a specific structure of data frames is defined, including a plurality of data fields within each data frame. Due to limitations of communication protocols and considerations of maximum frame length, data and status information of a device is often scattered over multiple data frames for transmission. To facilitate the integration and processing of data, each data field in the interface definition document may be associated with a particular data class label. The purpose of these labels is to group fields that have common properties or functions into one class, forming a virtual class of data. By the method, the generated graphical user interface has interface friendliness, and the displayed data of the final interface are large, so that the related data are converged and displayed, and a user can easily see the data wanted; secondly, the mapping of the interface is convenient, and one data class is corresponding to one minimum area of the interface. The modification and adjustment of the local interface are facilitated, and the direct control of the target program based on the modified file is needed to be completely regenerated after the modification of the text configuration file of the interface is not needed like in the prior art.

The embodiment of the application provides a graphical user interface generation method, as shown in fig. 1, which comprises steps S101 to S106. Wherein fig. 1 is only one execution order shown in the embodiment of the present application, and does not represent the only execution order of a graphical user interface generating method, and the steps shown in fig. 1 may be executed in parallel or upside down in case that the final result can be achieved.

S101: an initial protocol definition profile is generated based on the protocol interface definition document.

Specifically, the protocol interface definition document is an interface definition document (ICD) of the unmanned aerial vehicle ground detection protocol, and the initial protocol definition configuration file is a file in an extensible markup language (XML) format.

Fig. 2 is a specific flowchart of generating an initial protocol definition configuration file based on a protocol interface definition document according to an embodiment of the present application, as shown in fig. 2, including steps S201 to S203.

S201: the read protocol interface defines a document.

In particular, an interface definition document (ICD) of the unmanned aerial vehicle ground detection protocol may be read using an automation tool or software, and this protocol interface definition document contains various protocol information required for communication between the unmanned aerial vehicle and the ground station, including data frame formats, field definitions, and the like.

S202: and according to the preset data definition identification protocol interface definition document, converting the target data into the data of the first data structure.

Specifically, the preset data definition is a section of formatted text defined by a user and used for describing characteristics or modes of target data, so that required target data can be accurately extracted from the document, and the required data components can be accurately extracted from the document by using the preset data definition. For example, if the first data contains a plurality of fields, such as "field 1", "field 2", and "field 3", and the fields have a specific arrangement and format in the document, the preset data definition may locate and extract the values of the fields according to the structure information. The target data is specific information that needs to be extracted from the first data structure defining document for the protocol interface, and may be key table contents, but may be any other type of data, such as specific fields, parameters, attributes, etc. Once the target data is extracted, it will be converted into data of the first data structure. The first data structure contains information such as byte offset value, occupied byte number, bit segment offset, field name, data unit, coding format, minimum resolution of data, remark, display dictionary (text information corresponding to different values), etc. of the corresponding field.

S203: formatting the data of the first data structure generates an initial protocol definition configuration file.

In particular, the initial protocol definition profile is typically saved in XML format because it has good readability and extensibility.

S102: adding a data class label to a field in the initial protocol definition configuration file generates a final protocol definition configuration file. Wherein the data class corresponds to a sub-region in the graphical user interface, and the data class label comprises a multi-layer class name from high to low.

The development efficiency problem of manually editing the graphical interface is solved by the scheme, and the problem that software defects are easily introduced in manually editing the graphical interface is avoided. In addition, compared with a method for directly controlling a target program to present a graphical user interface by using a text configuration file with DSL (English: domain Specific Language Chinese: domain-specific language) effect, the method can conveniently and flexibly adjust the interface layout and support various personalized customization controls.

Specifically, the initial protocol definition configuration file contains detailed definitions of the unmanned aerial vehicle detection data frames, including a plurality of data frames and data fields therein. For each data field in the initial protocol definition configuration file, a data class label is manually configured for the data field, and the data class label is used for identifying the data class to which the field belongs, namely a group of field sets with common attributes or functions. The data class labels may contain multiple levels of class names from high to low in order to logically organize the data more clearly. Each dataclass logically corresponds to a sub-region in a Graphical User Interface (GUI). This means that when data is sent from the drone and processed, fields belonging to the same class of data will be displayed in the same sub-area of the graphical user interface. Each field under the dataclass will be mapped onto a set of controls for the corresponding sub-region on the graphical user interface. These controls are responsible for displaying the actual data of the fields, such as text lists, charts, indicators, etc. The type and layout of the controls depends on the type and importance of the fields. After the data class labels of all the fields are configured, the initial protocol definition configuration file is saved as the final protocol definition configuration file. The final protocol definition configuration file now contains data class label information for each field so that subsequent data processing and graphical user interface displays can be organized by data class. Before the final protocol definition configuration file is used in the actual system, the necessary verification and testing can be performed to ensure the correct configuration of the data class labels and the accuracy of the graphical user interface display.

FIG. 5 is a diagram illustrating a relationship between a data class and a graphical user interface according to an embodiment of the present application. As shown in fig. 5, the graphical user interface is divided into different sub-areas for displaying data received from the drone. These sub-regions correspond to particular data classes, each of which contains a set of fields that have a common attribute or function. For example, data class 1 corresponds to sub-region 1 in the graphical user interface, sub-region 1 being a text list region for showing the actual data of all fields under data class 1. Likewise, data class 2 corresponds to sub-region 2 in the graphical user interface, and sub-region 2 is also a text list region for displaying data in the lower field of data class 2. Through the mapping relation, a user can intuitively view and understand various information sent by the unmanned aerial vehicle.

Further, the general form of the initial protocol definition profile and the final protocol definition profile is ：<?xml version="1.0" encoding="UTF-8"?><icd-def><block id="1" name="DiJianShuJuZhen1" title=" to examine data frame 1"> < segment > </block > </icd-def >" as shown below.

Specifically, in the configuration file, the < segment > tag represents a data field, and the class attribute is used to specify the data class tag to which the field belongs. The data class labels adopt a hierarchical structure, such as 'class 1, class 2 and class 3', wherein the classification names of the high level are in front, and the classification names of the low level are in back and are connected through point numbers (").

And identifying target data in the protocol interface definition document by using preset data definition, wherein the preset data definition defines the corresponding relation between the table head column and the data type of the table. In the following, two preset data definitions are taken as examples, and the preset data definition 1 is: byteOffset = byte sequence number; byteCount = number of bytes; name = parameter Name; unit = Unit; format = Format; scale = resolution; comment = remark; the preset data definition 2 is: bitOffset = BIT, BITs; name = definition; dict = validity, description, remarks, status word.

In the preset data definition, the word on the left of the equal sign indicates the type of data, the right of the equal sign indicates the possible header names, a plurality of the possible header names are separated by commas, and different data type definitions are separated by semicolons. By reading these preset data definitions, an expression object (e.g., e 1) is constructed, the object e1 containing a plurality of states and operations, the two most predominant operations being a matching operation and a fetching operation. The matching operation is used for identifying whether the header of the table is matched with the header described by the preset data definition or meets the similarity relation; the extraction operation obtains the column position of the data from the preset data definition statement according to the data type parameter, and then extracts the data of the appointed type from the table. It should be noted that the foregoing preset data definition is only exemplary, and the present application is not limited by the foregoing preset data definition.

Further, in the present application, an initial protocol definition configuration file is generated based on a protocol interface definition document, and the detailed steps of adding a data class label to a field in the initial protocol definition configuration file to generate a final protocol definition configuration file are as follows.

1. And reading preset data definitions, and reading the preset data definitions to construct an expression object e1. This object contains matching rules and extraction rules between the data fields and the table column header.

2. And opening an interface definition document by using a Word document operation API provided by Microsoft to obtain a document object d1, namely an initial protocol definition configuration file.

3. All table objects are extracted from the document object d1 and stored in the list L1.

4. Each table object t1 in L1 is traversed, checking whether its first row data r1 matches the definition in expression e 1.

5. If so, the table object t1 is added to the list L2 for subsequent processing.

6. Each table object t2 in list L2 is traversed.

7. Traversing each row of data r2 of t2, extracting field information from r2 using rules in expression object e 1.

8. The extracted field information includes a field name n1, an offset position o1, a byte number c1, an encoding parameter p1, and a dictionary list i1.

9. A data structure b1 is created using these field information and b1 is added to the list L3.

10. The data structure b1 in list L3 is converted into an XML subtree.

11. This XML subtree is incorporated into the XML document object X1.

12. Repeating the steps until all the table objects in the L2 are processed.

13. The XML document object X1 is formatted to ensure that the generated XML file conforms to the intended format and structure.

14. The formatted X1 is saved as a final protocol definition configuration file that now contains all relevant information extracted from the interface definition document.

S103: and acquiring the current interface layout file as an initial interface layout file.

Specifically, the current interface layout file refers to a basic or original interface layout which is not subjected to any data binding and control addition, and the current interface layout file is taken as an initial interface layout file.

Fig. 6 is a schematic diagram of an initial interface layout without content according to an embodiment of the present application. As shown in fig. 6, the initial interface layout may have only a basic structure, with no controls for displaying data. Fig. 7 is a schematic diagram of an initial interface layout with content according to an embodiment of the present application, where, as shown in fig. 7, the initial interface layout may be a control for adding display data to a layout designated area.

S104: and determining the target position of each data class in the initial interface layout file and the corresponding interface generation template based on the data binding file.

FIG. 8 is a schematic diagram of a possible content interface of an initial interface layout file according to an embodiment of the present application. As shown in fig. 8, a plurality of display pages may be included, and each display page may include a plurality of display areas.

Specifically, the data binding file is a structured document that needs to be written manually in advance, which describes how virtual dataclasses are mapped to specific locations in the interface layout and interface generation templates used. And determining a target position of each data class (virtual data class) in the initial interface layout file according to a rule specified by the data binding file, wherein the target position comprises a corresponding initial interface layout file name and a parent control name of the displayed position.

Further, the data binding file also includes an operation policy prior to generation, including whether to empty all children of the target parent control container, to ensure that newly added controls do not conflict with existing controls. The operation policy before generation refers to an operation that needs to be performed before adding the control set to the initial interface layout file.

Specifically, the system needs to analyze the data binding file, and reads the mapping rule and the interface generation template information in the data binding file. According to the mapping rules in the data binding file, the system matches each virtual data class with a target location in the initial interface layout file. The target location is determined by the name of the initial interface layout file and the name of the parent control. And allocating a corresponding interface generation template for each data class. Based on the control type and parameter information in the template, the system will know how to generate interface controls for the data class. Before adding the control set to the initial interface layout file, the system may perform a corresponding operation, such as emptying children of the target parent control container, according to the pre-generation operation policy.

Specifically, the interface generation template includes names and parameters, the names including one or more control types, such as label controls, text controls, button controls, and the like. The parameters are used for determining the column number of the generating unit and the column where each control type is located. Control types include, but are not limited to, a label control and a text control.

S105: and generating a corresponding control set by using fields under each data class in the final protocol definition configuration file based on preset generation rules in the file of the interface generation template.

Specifically, the final protocol definition configuration file contains data class information extracted from the interface definition document.

The preset generation rules in the file of the interface generation template comprise control types (such as label controls, text controls and the like), the number of columns of the controls, the columns where the control types are located and the like. According to these rules, a set of controls corresponding to the data class fields is generated, which will be used to update the initial interface layout file, generating the final interface layout file.

Fig. 3 is a specific flowchart of generating a corresponding control set based on a preset generation rule in a file of an interface generation template according to fields under each data class in a final protocol definition configuration file according to an embodiment of the present application, as shown in fig. 3, including steps S301 to S304.

S301: and reading the final protocol definition configuration file, and performing aggregation based on the data class labels.

Specifically, the final protocol definition configuration file typically contains all data class definitions of the application, and the data classes are aggregated based on data class labels (e.g., class names or type identifiers) for subsequent processing.

S302: and converting each aggregated data class into a corresponding first multi-way tree.

Fig. 9 is a schematic diagram of a tree structure corresponding to the content of an initial interface layout file according to an embodiment of the present application. As shown in fig. 9, each layout window may have a plurality of display pages, and each display page may have a plurality of display areas.

Specifically, after the dataclasses are aggregated, each dataclass is converted into a first multi-way tree (i.e., a tree structure of dataclasses). The first multi-way tree represents the hierarchical structure and field relationships of the dataclass. The nodes of the tree may represent fields in the data class, while the child nodes may represent subfields or attributes of the fields.

Fig. 10 is a schematic tree structure diagram of converting aggregated data classes into a corresponding first multi-tree according to an embodiment of the present application. As shown in fig. 10, each dataclass may include a plurality of fields.

S303: and acquiring a preset generation rule of the corresponding data class from the file of the interface generation template.

Specifically, a file of the interface generation template is consulted, and the file contains a generation rule for how to convert the data class into the interface control. And finding out a corresponding preset generation rule in the file of the interface generation template according to the label of the data class. These rules define how the interface controls are created and laid out from the fields of the dataclass.

S304: and generating a control tree corresponding to the corresponding first multi-tree based on a preset generation rule to serve as a control set.

Specifically, after the generation rule is set, the control tree can be generated according to the first multi-way tree and the preset generation rule, and the control tree is used as a control set. Each node of the control tree represents an interface control, and the relationship (such as parent-child relationship) among the controls reflects their layout and hierarchy on the interface.

S106: and adding the control set to a corresponding target position in the initial interface layout file to form a final interface layout file.

Fig. 4 is a specific flowchart of adding a control set to a corresponding target position in an initial interface layout file to form a final interface layout file according to an embodiment of the present application, as shown in fig. 4, including steps S401 to S405.

S401: generating an initial multi-way tree based on the initial interface layout file, generating corresponding access path identifiers for control container nodes in the interface layout file, and forming an association table of control names and corresponding access path identifiers, wherein each control container corresponds to one data class.

Fig. 11 is a schematic diagram of an initial interface layout file tree structure corresponding to a data class according to an embodiment of the present application. As shown in FIG. 11, the tree structure depicts an initial user interface layout file in which each control container node, the vertical list container, corresponds to a data class. A dataclass typically contains a number of fields that are presented on an interface through corresponding controls. In this embodiment, for simplicity of representation, it is assumed that each data class corresponds to a plurality of textbox controls for displaying different field values in the data class.

S402: and obtaining the control name corresponding to the control tree.

S403: and inquiring the access path identification corresponding to the control name based on the association table.

S404: and adding the control tree to the corresponding control container node of the initial multi-way tree based on the access path identification to form a final multi-way tree.

S405: and generating a final interface layout file based on the final multi-way tree.

The above process will be described with reference to one embodiment, but of course, other embodiments are possible, and the present application is not limited to this embodiment.

And reading a final interface layout file which contains the data class definitions required by the application. The system uses a parser to parse the configuration file into a second data structure, wherein the second data structure is a list comprising a number of first data structures. Each first data structure represents a data class, including field information and attributes of the data class.

And acquiring a preset generation rule of the corresponding data class from the file of the interface generation template. The file of the interface generation template contains rules that instruct how to convert the first data structure in the second data structure to the set of interface controls. These rules define how the corresponding interface controls are generated from the field information of the dataclass and specify the layout and style of the controls.

An initial interface layout file is read, which describes the initial layout of the user interface. The initial interface layout file is processed into a multi-drop tree a using a layout parser. Each node of the multi-way tree A represents a control or a control container on the interface, and the relation among the nodes reflects the hierarchical structure and layout relation of the control on the interface. To facilitate subsequent operations, an identification A is generated for each node representing a control container. Identification a is an access path from the root node of the tree to the current node for uniquely identifying a control container node. The system also generates an association table A, wherein the key value is a control name and the value is a corresponding identifier A.

When modification operations are performed on the interface layout, such as adding or deleting controls, the modification to the multi-tree A can be considered. Such modification typically involves adding or deleting subtrees in the tree, resulting in a new multi-way tree a'. If only the content inside the interface structure is modified without changing the overall layout, these changes occur mainly near the leaf nodes. In the multi-way tree A and the multi-way tree A', the identifier A can be used for uniquely identifying and tracking equivalent nodes before and after the change. Wherein, the multi-tree A is an initial multi-tree, and the multi-tree A' is a final multi-tree.

Using the identification a instead of the control name as the identifier of the node has the following advantages: firstly, confusion caused by the same name of the control is avoided; secondly, the corresponding node can be directly accessed according to the path information in the identifier A; finally, by comparing the identifications A of the two nodes, the relationship between the two nodes in the same tree can be judged.

The second data structure is converted into a set of multi-tree, called multi-tree set a, according to a preset generation rule. The set of multi-way trees represents the interface layout content corresponding to the data class field information. For example, if a data class contains a, b, c, d four fields and it is desired to present these fields in list form, the data class is first converted to a tree structure and then a corresponding control tree is generated for each field node.

And inquiring the corresponding identifier A from the association table A according to the control name according to the operation of the user or a preset rule. Using this identification A, control container nodes in the multi-drop tree A can be located. Then, a plurality of multi-tree (i.e. control tree) in the multi-tree group A is used as subtree to be added under the control container nodes, and the merging operation of the interface layout is completed.

Fig. 12 is a schematic diagram of interface layout and control tree merging according to an embodiment of the present application. As shown in fig. 12, there is an interface layout window that contains two empty sub-regions, referred to as display region 1 and display region 2. These two sub-regions correspond to two control container nodes in the multi-way tree a, respectively. There is a set of multiple tree groups a that represent interface control trees generated based on the second data structure. In this example, the multi-tree group a contains three root nodes, placement container 1, placement container 2, and placement container 3, respectively. Each layout container node may include one or more nodes of interface controls that describe specific presentation elements (e.g., text boxes, buttons, etc.) on the interface. And reading the interface layout file, and inquiring the corresponding identifier A from the association table according to the control name. This identification a is a path indicating the location from the root node of the multi-drop tree a to a particular control container node. These identifications a are used to locate control container nodes (display area 1 nodes in this example) in the multi-drop tree a. Each of the multi-tree in the multi-tree group a (i.e., the placement container 1, placement container 2, and placement container 3) is added as a subtree below the display area 1 node. After this merging process is completed, an updated multi-way tree a' is obtained, which contains the original layout (display area 1 and display area 2) and the newly added control tree (layout container 1, layout container 2 and layout container 3). This new multi-drop tree a' describes the modified interface layout and is ready to be formatted into a final interface layout file for subsequent user interface rendering and presentation. The combined multi-way tree a is converted into a user interface layout description, which is usually a description file or code segment, and contains information such as the type, position, attribute and the like of the interface elements. This description file is saved as a final interface layout file and can be used directly for rendering and presentation of the user interface.

Further, the present application will dynamically generate and modify user interface layouts in detail as follows.

1. First, a data binding file is read, and a binding information table BT1 is created based on the content thereof.

2. The final protocol definition profile is read and a data class list DL1 is created accordingly.

3. An empty association table TM1 is created for storing control tree objects and their corresponding interface layout file names.

4. Each entry I1 in the binding information table BT1 is traversed.

5. The name N1 of the interface layout file is acquired from the entry I1.

6. An attempt is made to obtain the control tree object assignment variable T1 from the association table TM1 using N1 as a key.

7. If T1 is empty, the corresponding interface layout file is loaded from the external memory by using N1, and an interface layout object T1 is created and added to the association table TM 1.

8. Traversing the control tree in the interface layout object T1 to generate a control name-access path identification association table CB1.

9. And acquiring the generated template name N2 from the item I1, loading a corresponding interface generated template, and creating a generated template object M1.

10. The name N3 of the data class is obtained from the entry I1, and the data class object C1 is obtained from the data class list DL1 using N3.

11. An empty control tree list CT1 is created.

12. Traversing the field information set in C1, processing each field S1 by using the generated template object M1, and adding the generated control tree object into CT 1.

13. The control name C2 is obtained from the item I1, the corresponding control path identification is queried in the association table CB1 by using the C2, after the corresponding control node CN1 is found, the control interface CN1 is processed by using the generated template object M1, and each control tree in the CT1 is added under the CN1 node in sequence.

14. After all the entries in the binding information table BT1 are processed, traversing the association table TM1, formatting the modified interface object according to the ui file format, and storing the interface object into an external memory.

In particular, the above-described flow ensures that user interface layouts can be dynamically generated and modified based on data binding files and data class lists, thereby enabling efficient binding and presentation of interfaces and data.

Further, in the above-described embodiment, ui files of QT graphical interface technology are used as user interface layout definition files, which are essentially in XML document format, defining the composition structure of the interface in the form of a multi-way tree. The nodes of each tree represent either a control itself or the attribute values of the control. To uniquely identify an XML document node in a ui file, an expression in XPath format, called identity A, is used. For example, the expression "ui/widget/layout [1]/item [1]/widget [2]" indicates that, starting from the root node "ui", the "widget" node, the first "layout" node, the first "item" node, and the second "widget" node are sequentially selected so as to precisely locate the target control node. In order to establish the correspondence between the data class and the interface display, a data binding file is introduced, which is a text file in XML format. This document describes how the content of the dataclass is embedded on the control tree of the graphical user interface. The data binding file contains a plurality of < item > entries, each specifying a name of the ui file, a name of the target location parent control, a data class label name, a prefix name of the generation control, a maximum line number limit, an operation policy before generation, and an interface generation template name. The specific content and form of the data binding file is as follows.

< Bind > < item ui= "page1.Ui" widget= "layout1" class= "data class 1" prefix="data1" maxRow="12" begin="ClearItems" process="LabelTextLine"/><item ui="page2.ui" widget="gridLayout_3" class=" data class 2" prefix="data2" maxRow="5" begin="SetIndex(1)" process="process="LabelTextLine(0,3,4)""/>…</bind>. interface generation template name format is" name [ (parameter 1, parameter 2) ] ", wherein the name is a necessary filling item, and the parameter is optional filling content for influencing final interface generation effect. For example, "LabelTextLine (0, 3, 4)" means that a combined label control and text control is generated, with 4 columns as a minimum generating unit, a label is placed in column number 0, and a text box is placed in column number 3.

Fig. 13 is a schematic diagram of a first result of the generation interface according to the embodiment of the present application. As shown in fig. 13, the control corresponding to field 1 is an input box (or text edit box) in which a user can input text. Similarly, the control corresponding to field 2 is also an input box, allowing the user to enter text. Fig. 14 is a schematic diagram of a second result of the generation interface according to the embodiment of the present application. As shown in fig. 14, field 1 and field 2 correspond to a combination of three controls, respectively. The first two controls are labels or static text for displaying the prompt "text", while the third control is an input box allowing the user to enter text.

The embodiment of the application also provides a graphical user interface generating device 1500, as shown in fig. 15, which comprises: a generate file module 1501, an add tag module 1502, an acquire module 1503, a determine module 1504, a generate aggregate module 1505, and an add location module 1506.

The generation file module 1501 is used to generate an initial protocol definition configuration file based on the protocol interface definition document.

The add tag module 1502 is configured to add a data class tag to a field in the initial protocol definition profile to generate a final protocol definition profile, wherein the data class corresponds to a sub-region in the graphical user interface.

The obtaining module 1503 is configured to obtain a current interface layout file as an initial interface layout file.

The determining module 1504 is configured to determine, based on the data binding file, a target location of each data class in the initial interface layout file and a corresponding interface generation template.

The generation set module 1505 is configured to generate a corresponding control set based on a preset generation rule in the file of the interface generation template from the fields under each data class in the final protocol definition configuration file.

The adding location module 1506 is configured to add the control set to a corresponding target location in the initial interface layout file to form a final interface layout file.

Some of the modules of the apparatus of the present application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, classes, etc. that perform particular tasks or implement particular abstract data types. The application may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

The apparatus or module set forth in the embodiments of the application may be implemented in particular by a computer chip or entity, or by a product having a certain function. For convenience of description, the above devices are described as being functionally divided into various modules, respectively. The functions of each module may be implemented in the same piece or pieces of software and/or hardware when implementing the embodiments of the present application. Of course, a module that implements a certain function may be implemented by a plurality of sub-modules or a combination of sub-units.

The methods, apparatus or modules described in this application may be implemented in computer readable program code means and in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, application specific integrated circuits (english: application SPECIFIC INTEGRATED Circuit; ASIC), programmable logic controller and embedded microcontroller, examples of the controller including but not limited to the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller can be regarded as a hardware component, and means for implementing various functions included therein can also be regarded as a structure within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.

As shown in fig. 16, an embodiment of the present application further provides a gui generating server, including a memory 1601 and a processor 1602; the memory 1601 is for storing computer-executable instructions; the processor 1602 is configured to execute computer-executable instructions to implement a graphical user interface generation method as described above in accordance with embodiments of the present application.

The embodiment of the application also provides a computer readable storage medium which stores executable instructions, and the computer can realize the method for generating the graphical user interface.

From the above description of embodiments, it will be apparent to those skilled in the art that the present application may be implemented in software plus necessary hardware. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product or may be embodied in the implementation of data migration. The computer software product may be stored on a storage medium, such as ROM/RAM, magnetic disk, optical disk, etc., and include instructions for causing a computer device (which may be a personal computer, mobile terminal, server, or network device, etc.) to perform the methods described in the embodiments of the present application.

In this specification, each embodiment is described in a progressive manner, and the same or similar parts of each embodiment are referred to each other, and each embodiment is mainly described as a difference from other embodiments. All or portions of the present application are operational with numerous general purpose or special purpose computer system environments or configurations.

The above embodiments are only for illustrating the technical solution of the present application, and not for limiting the present application; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some or all of the technical features thereof can be replaced with equivalents; such modifications and substitutions do not depart from the spirit of the application.

Claims (9)

1. A method for generating a graphical user interface, comprising:

generating an initial protocol definition configuration file based on the protocol interface definition document;

Adding a data class label to a field in the initial protocol definition configuration file to generate a final protocol definition configuration file; wherein the data class corresponds to a sub-region in the graphical user interface;

Acquiring a current interface layout file as an initial interface layout file;

Determining target positions of all data types in the initial interface layout file and corresponding interface generation templates based on the data binding file;

generating a corresponding control set by fields under each data class in the final protocol definition configuration file based on preset generation rules in the file of the interface generation template;

Generating a corresponding control set based on a preset generation rule in a file of the interface generation template by using fields under each data class in a final protocol definition configuration file, wherein the control set comprises: reading the final protocol definition configuration file, and aggregating based on the data class labels; converting each data class after aggregation into a corresponding first multi-way tree; acquiring a preset generation rule of a corresponding data class from a file of the interface generation template; generating a control tree corresponding to the corresponding first multi-tree based on the preset generation rule as a control set;

Adding the control set to a corresponding target position in the initial interface layout file to form a final interface layout file;

the adding the control set to the corresponding target position in the initial interface layout file to form a final interface layout file comprises the following steps: generating an initial multi-way tree based on the initial interface layout file, and generating a corresponding access path identifier for a control container node in the interface layout file; adding the control tree under a corresponding control container node of the initial multi-way tree based on the access path identifier to form a final multi-way tree; and generating a final interface layout file based on the final multi-way tree.

2. The method of claim 1, wherein the target location comprises a corresponding initial interface layout file name and a parent control name for the displayed location.

3. The method of generating a graphical user interface of claim 2, wherein the data binding file further comprises a pre-generation operation policy comprising whether all children of the target parent control container are emptied.

4. A method of generating a graphical user interface according to claim 1, wherein the interface generation template comprises a name and parameters, the name comprising one or more control types, the parameters being used to determine the number of columns of the generation unit and the columns in which each control type is located.

5. The method of generating a graphical user interface according to claim 1, wherein generating an initial protocol definition profile based on a protocol interface definition document comprises:

Reading a protocol interface definition document;

Identifying target data in the protocol interface definition document according to preset data definition, and converting the target data into data of a first data structure;

formatting the data of the first data structure to generate an initial protocol definition configuration file.

6. The method of generating a graphical user interface of claim 1, further comprising:

Forming an association table of control names and corresponding access path identifications, wherein each control container corresponds to one data class;

Acquiring a control name corresponding to the control tree;

And inquiring the access path identification corresponding to the control name based on the association table.

7. The method of claim 1, wherein the data class labels comprise a top-to-bottom multi-layer class name.

8. A graphical user interface generation apparatus, comprising:

the generating file module is used for generating an initial protocol definition configuration file based on the protocol interface definition file;

The adding tag module is used for adding a data class tag to a field in the initial protocol definition configuration file to generate a final protocol definition configuration file, wherein the data class corresponds to a sub-area in a graphical user interface;

The acquisition module is used for acquiring the current interface layout file as an initial interface layout file;

The determining module is used for determining the target position of each data class in the initial interface layout file and the corresponding interface generating template based on the data binding file;

The generation set module is used for generating a corresponding control set by fields under each data class in the final protocol definition configuration file based on a preset generation rule in the file of the interface generation template; generating a corresponding control set based on a preset generation rule in a file of the interface generation template by using fields under each data class in a final protocol definition configuration file, wherein the control set comprises: reading the final protocol definition configuration file, and aggregating based on the data class labels; converting each data class after aggregation into a corresponding first multi-way tree; acquiring a preset generation rule of a corresponding data class from a file of the interface generation template; generating a control tree corresponding to the corresponding first multi-tree based on the preset generation rule as a control set;

The adding position module is used for adding the control set to the corresponding target position in the initial interface layout file to form a final interface layout file; the adding the control set to the corresponding target position in the initial interface layout file to form a final interface layout file comprises the following steps: generating an initial multi-way tree based on the initial interface layout file, and generating a corresponding access path identifier for a control container node in the interface layout file; adding the control tree under a corresponding control container node of the initial multi-way tree based on the access path identifier to form a final multi-way tree; and generating a final interface layout file based on the final multi-way tree.

9. A computer-readable storage medium, wherein the computer-readable storage medium stores executable instructions, a computer capable of implementing the method of any one of claims 1-7 when executing the executable instructions.