Code generation method and device for desktop component, equipment and medium

Abstract

The invention provides a code generation method for a desktop component, and relates to the field of computer application, and the method comprises the steps: obtaining input data which is used for representing description of functional features and / or appearance features of the desktop component needing to be generated; and inputting the input data into a pre-trained language transformation model to obtain a component description language which is used for describing the desktop component by adopting a structured grammar. And finally, generating code data of a protocol format supported by the target platform according to the component description language and a pre-stored component generation rule of the target platform. According to the method, input data is taken as an entry, a large model is firstly refined into a field-specific language (DSL) described by an intermediate component related to an operating system, and then the DSL is converted into a protocol code supported by a manufacturer by using a pre-stored manufacturer forced specification set, so that a technician does not need to write an adaptive code for the manufacturer, and the operation efficiency is improved. Therefore, the problems of high development cost, high development difficulty and human resource waste are directly solved.

Description

Technical Field

[0001] This disclosure relates to the field of computer application technology, and in particular to a method, apparatus, device and medium for generating code for desktop components. Background Technology

[0002] In recent years, with the widespread adoption of smart electronic devices, desktop widgets displayed on these devices have become a crucial entry point for providing users with intelligent and convenient services, playing a significant role in enhancing user experience. Users expect to see information such as weather, schedules, logistics, and video updates at a glance on their lock screen or home screen. Consequently, the capabilities of operating systems and desktop widgets provided by various manufacturers have become key entry points for applications vying for user attention.

[0003] Currently, there are shortcomings in the development process of existing desktop components. For example, in order to improve user experience, mobile phone manufacturers have introduced customized desktop component protocols (such as desktop cards). These manufacturer-specific protocols are often complex in structure and differ from the native operating system's desktop component protocols, requiring developers to manually write specific adaptation code for each manufacturer. This process is professional and cumbersome, significantly increasing development difficulty, costs, and the workload of technical personnel, leading to wasted resources. Summary of the Invention

[0004] To solve the above-mentioned technical problems, or at least partially solve them, this disclosure provides a method, apparatus, device, and medium for generating code for desktop components.

[0005] This disclosure provides a method for generating code for a desktop component, the method comprising: The process involves acquiring input data, which describes the functional and / or appearance features of the desktop components to be generated. This input data is then fed into a pre-trained language transformation model to obtain a component description language. This component description language can be used to describe the desktop components using a structured syntax. Finally, based on the component description language and pre-stored component generation rules for the target platform, code data in a protocol format supported by the target platform is generated. The component generation rules for the target platform can be a set of mandatory technical specifications for user interface element types, attribute fields, hierarchical structures, and data bindings within the target platform's custom rendering framework.

[0006] This disclosure also provides a desktop component code generation apparatus, the apparatus comprising: An acquisition unit is used to acquire input data, which is used to characterize the functional and / or appearance features of the desktop component to be generated; An input unit is used to input the input data into a pre-trained language transformation model to obtain a component description language, which is used to describe the desktop components to be generated using a structured syntax. The first generation unit is used to generate code data in the protocol format supported by the target platform according to the component description language and the pre-stored component generation rules of the target platform. This disclosure also provides a computing device, the computing device comprising: a processor; a memory for storing executable instructions of the processor; the processor being configured to read the executable instructions from the memory and execute the instructions to implement a code generation method for a desktop component as provided in this disclosure.

[0007] This disclosure also provides a computer-readable storage medium storing a computer program for executing a code generation method for a desktop component as provided in this disclosure. Attached Figure Description

[0008] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0009] Figure 1 A flowchart illustrating a method for generating code for a desktop component according to an embodiment of this disclosure; Figure 2 A schematic diagram of the structure of a code generation device for a desktop component provided in an embodiment of this disclosure; Figure 3 This is a schematic diagram of the structure of a computing device provided in an embodiment of the present disclosure. Detailed Implementation

[0010] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0011] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0012] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0013] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0014] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0015] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0016] In recent years, with the popularization of smartphones, intelligence and convenience have become the focus of terminal manufacturers and application providers. As an important entry point for providing users with intelligent and convenient services, desktop widgets play an important role in improving user experience.

[0017] Users expect to see information such as weather, schedules, logistics, and video updates at a glance on the lock screen or home screen. The "desktop widget" framework provided by Android and the "desktop widget" capabilities launched by various manufacturers have become key entry points for various applications to compete for user attention.

[0018] Currently, there are still shortcomings in the development process of existing desktop components. For example, in order to improve user experience, mobile phone manufacturers have introduced customized desktop component protocols. These manufacturer-specific protocols are usually complex in structure and differ from the native operating system's desktop component protocols, requiring developers to manually write specific adaptation code for each manufacturer. This process is professional and cumbersome, significantly increasing development difficulty, development costs, and the workload of technical personnel, resulting in wasted resources.

[0019] In view of this, this application provides a method for generating code for desktop components, including acquiring input data, wherein the input data is used to characterize the functional and / or appearance features of the desktop component to be generated. The input data is then fed into a pre-trained language translation model to obtain a component description language, wherein the component description language can be used to describe the layout and content of the desktop component using a structured syntax. Finally, code data in a protocol format supported by the target platform is generated based on the component description language and pre-stored component generation rules for the target platform, wherein the component generation rules for the target platform can be a set of mandatory technical specifications in the target platform's custom rendering framework regarding user interface element types, attribute fields, hierarchical structures, and data bindings.

[0020] This application uses "writing a natural language description once" as the sole entry point, first refining the large model into a platform-independent intermediate DSL, and then using a pre-built set of mandatory specifications from various vendors to convert this DSL into vendor-supported protocol code. In this way, technical personnel do not need to write adaptation code for each vendor by hand, thus directly solving the problems of high development costs, high development difficulty, and waste of human resources.

[0021] To address the aforementioned issues, this disclosure provides a method for generating code for desktop components, which will be described below with reference to specific embodiments.

[0022] Figure 1 This is a flowchart illustrating a method for generating code for a desktop component according to an embodiment of the present disclosure. This method can be executed by a code generation device for a desktop component, wherein the device can be implemented in software and / or hardware, and is generally integrated into a computing device. Figure 1 As shown, the method includes: S11: Obtain input data.

[0023] The computing device can acquire input data, which describes the functional and / or appearance features of the desktop component to be generated (also called the target desktop component). The appearance features of the target desktop component may include, for example, its size (e.g., a 4x2 daily trending cards) and layout structure (e.g., thumbnails displayed on the left, and a list of titles on the right). The functional features of the target desktop component reflect its functional requirements. For example, the first row could have a 16:9 mini-player embedded on the left to play trailers in real time, with a VIP badge overlaid on the right; the second row could display the series name and episode number on the left, with trending comments displayed on the right in a marquee format; clicking the card could directly take you to the corresponding main episode playback page and automatically skip the intro. Desktop components are lightweight visual modules provided by the operating system that can be directly embedded into the desktop interface to display information in real time or provide quick operations without launching a full application; examples include desktop cards.

[0024] For example, the input data could be "a 4x2 daily trending cards, displaying thumbnails on the left and a list of titles on the right." Or, for instance, the input data could be "a 4x2 playback card, with a 16:9 mini-player embedded on the left of the first row playing trailers in real-time, and a VIP badge superimposed on the right; the second row displays the series name and episode number on the left, and trending comments on the right in a marquee format; clicking the card directly leads to the corresponding full-length playback page and automatically skips the intro." It should be noted that those skilled in the art can set the specific content of the input data according to their needs.

[0025] S12: Input the input data into a pre-trained language transformation model to obtain the component description language.

[0026] Computing devices can feed input data into a pre-trained language transformation model to obtain a Domain-Specific Language (DSL), also known as a domain-specific language for describing small components. This DSL is used to describe the layout and content of desktop components using a structured syntax. The pre-trained language transformation model can be, for example, a Transformer model; however, this is just an example and not a specific limitation.

[0027] For example, let's take the input data as "a 4x2 daily trending cards, with thumbnails displayed on the left and a list of titles displayed on the right" as an example.

[0028] The computing device can perform semantic analysis on the input data, such as identifying the component's dimensions (4x2), layout structure (images on the left, title lists on the right), and functional requirements (e.g., daily updates of "hot" content). The parsed results are organized into an intermediate representation, namely a domain-specific language (DSL) for component description. This DSL can express the component's layout and content using a structured syntax, such as describing the component's hierarchy, component type (e.g., images and text lists), and data binding (establishing an automatic, bidirectional, or unidirectional mapping between the displayed content of interface elements and external data sources, so that the interface elements can display the latest values ​​when the data source is updated). In this way, the user's intent can be accurately understood by the computing device and transformed into a standardized DSL.

[0029] In some possible implementations, computing devices can determine a user's reading habit data. For example, by analyzing behavioral data such as the user's swiping direction, page-turning gestures, text alignment, and information selection in input methods, browsers, or readers, the device can determine whether the user's reading habit is from left to right or from right to left. Then, the input data and the user's reading habit data are fed into a pre-trained language conversion model to obtain the component description language corresponding to the user's reading habit.

[0030] For example, when generating a Component Description Language (DSL), the language conversion model can automatically rearrange the left and right areas based on the user's reading habits, set the text alignment to right, set the list scrolling direction to right-to-left, and even synchronously flip the image and icon orientations in mirrored layouts. In the generated DSL example snippet, the ImageView node, originally located on the left, can be marked as "gravity=right," and the LinearLayout container on the right can be marked as "gravity=left," ensuring that the final rendering effect is consistent with the user's reading habits. Subsequent steps only require reading the orientation information already carried in the DSL.

[0031] If a user switches the reading direction in the settings, the computing device can regenerate a new DSL and hot-refresh the preview without further intervention from the developer.

[0032] In this way, while users are inputting data, their personal reading habits can be seamlessly integrated into the generation process. The final desktop components can meet both functional requirements and user reading habits, thereby improving the user experience.

[0033] S13: Generate code data in the protocol format supported by the target platform based on the component description language and the pre-stored component generation rules of the target platform.

[0034] The computing device can generate code data in the protocol format supported by the target platform based on the component description language and pre-stored component generation rules of the target platform. In other words, the computing device can map the component description language to the protocol format supported by the target platform according to the component generation rules, and generate code data in the protocol format supported by the target platform. It should be noted that manufacturers provide and maintain their own proprietary rendering platforms for their operating systems or desktop environments. The manufacturer and the platform can have a one-to-one correspondence, representing the same entity; that is, each manufacturer may have its own platform, and different platforms may support different component generation rules. Furthermore, this application can detect changes in the platform's component generation rules in real time. If a change is detected, the stored component generation rules can be updated in real time.

[0035] In some possible implementations, the computing device can convert the component description language into a desktop component layout code file (also called an Android XML layout code file) corresponding to the operating system (Android system is used as an example in this embodiment). The desktop component layout code file is used to characterize the arrangement and style of interface elements in the desktop component.

[0036] For example, in this embodiment, a LinearLayout container (used to arrange its subviews horizontally or vertically and control the alignment, weight, and spacing of the subviews on the main axis) can be used as the container, with its size set to the pixel size corresponding to a 4x2 unit. Then, child elements are added according to the structure specified by the DSL. For instance, the left area is converted into an image view component code data TextView occupying an appropriate width to display thumbnails, and the right area is converted into a vertical LinearLayout, which can sequentially contain several image text view component code data ImageViews for displaying a list of titles (such as the names and indices of trending content). This successfully maps the DSL description into interface layout code (i.e., desktop component layout code files) recognizable by the operating system (taking Android as an example).

[0037] Then, the computing device can map the desktop component layout code file to the protocol format supported by the target platform according to the component generation rules, and generate code data in the protocol format supported by the target platform.

[0038] For example, taking the Android system as an example, the target platform is the platform corresponding to manufacturer A (here we can call it platform A).

[0039] For example, Platform A provides a dedicated Software Development Kit (SDK) for rendering, requiring developers to describe interface cards in JSON format and provide data and bind views by inheriting the BaseDataPack class.

[0040] For example, a computing device can map image view component code data according to target component generation rules. Image view component code data in the desktop component layout code file is mapped to image component entries in the target component generation rules corresponding to platform A (which may include fields such as component type, image resource references, and layout position). Similarly, each text view component code data in the desktop component layout code file can be mapped to a text component entry in the target component generation rules corresponding to platform A (which may include text content placeholder fields, style, and position fields). Then, the image component entries and text component entries are combined according to the hierarchical structure specified in the target component generation rules. In this way, these JSON components can be combined into a layout structure that conforms to the vendor's specifications and encapsulated into a BaseDataPack data container via the rendering SDK.

[0041] In some possible implementations, this application can pre-store component generation rules for multiple platforms. This allows the same description (input data) to be transformed into the code of a desktop component supported by the corresponding platform, regardless of which platform the user's input data is to be mapped to. Thus, this invention ensures that the generated components have a consistent interface and interactive experience on Android native and various manufacturer platforms. A unified rendering interface and protocol adaptation module guarantee that the same DSL source can output the formats required by different platforms, eliminating display differences caused by different implementations, and ensuring that the widgets seen by users on different brand devices maintain a consistent appearance.

[0042] It should be noted that the Abstract Syntax Tree (a structured object in memory where the compiler uses nodes and edges to represent "what a component looks like and what attributes it has") and Android XML are isomorphic representations of each other. The Abstract Syntax Tree resides in memory, while Android XML is persisted (meaning that the Abstract Syntax Tree object, which originally only exists in memory, is saved to disk or transmission medium as an Android XML file, becoming a text file that can be stored for a long time and reread by the standard parser). After setting Android XML as the only intermediate representation, semantic verification and optimization can be completed and solidified within the closed space of the Abstract Syntax Tree - Android XML. Then, the verified Android XML can be directly mapped to any protocol using component generation rules. This centralizes the syntax analysis and constraint checks that originally needed to be repeated on each target platform into a single process, eliminating multiple repetitive tasks and completely decoupling platform differences from the source language.

[0043] In some possible implementations, after generating the code data (here referred to as the first code data), the computing device can call a unified interface to populate and render the component. For example, the data corresponding to the target field (e.g., a list of currently popular films) can be passed to the updateData(List films) interface method. That is, the data of the target field (e.g., film posters, titles, and popularity information) can be populated into the existing desktop component data (here referred to as the second code data), and the display can be refreshed immediately.

[0044] For example, if the generated code data is from the Android platform and the A platform, the Android RemoteViews mechanism and the A platform SDK interface can be called respectively to replace each TextView with the actual movie name and popularity text, and load the specified poster image resource into the ImageView. That is, only the runtime movie data (movie name, popularity and poster) is filled into the corresponding fields and a refresh is triggered so that the component immediately displays the latest content.

[0045] Because the underlying differences are encapsulated, users only need one command to update the component content across all platforms simultaneously.

[0046] In some possible implementations, the computing device can generate a preview interface for desktop components after updating the existing desktop layout data based on the code data. For example, the preview interface may display a simulated movie poster thumbnail on the left and a list on the right that can display the movie name and digital popularity value, with the overall layout matching the description.

[0047] For example, a computing device can read updated code data and then, at runtime, instantiate a render tree in the host environment according to the target platform's component generation rules. It then performs measurement, layout, and drawing processes on the render tree to generate a bitmap-style simulated interface. Placeholder data (generated based on data binding points and field types in the code data) can then be written to each component node in the render tree to simulate real content. Finally, the image can be output in real-time to an integrated development environment preview window or a standalone preview tool, supporting simulations of different screen sizes and styles. This allows for a direct and intuitive demonstration of component effects, essentially displaying a desktop component preview interface. This enables instant previewing and rapid iteration of descriptions (input data) without the need for repeated debugging on real devices or emulators. Users can complete component design and optimization in a shorter time. In some possible implementations, this application may also provide automatic code generation and registration support. For example, automatically generating template code for the component provider AppWidgetProvider and registering it in the global configuration file AndroidManifest.xml on the Android platform.

[0048] Platform A can generate the configuration or code snippets needed to register desktop components. Users simply need to integrate this automatically generated code into their application projects to complete component registration and deployment. This allows the generated components to be quickly rendered and run on the target platform.

[0049] This application can acquire input data, which represents a description of the desktop components to be generated. The input data is fed into a pre-trained language translation model to obtain a component description language, which uses a structured syntax to describe the layout and content of the desktop components. Finally, based on the component description language and pre-stored component generation rules for the target platform, code data in the protocol format supported by the target platform is generated. The component generation rules for the target platform are a set of mandatory technical specifications for user interface element types, attribute fields, hierarchical structures, and data binding within the target platform's custom rendering framework. This application uses writing a natural language description as the sole entry point, first refining the large model into an operating system-related intermediate DSL, and then automatically translating this DSL into corresponding supported protocol code using a pre-set set of mandatory specifications from various vendors. This eliminates the need for developers to manually write adaptation code for each vendor, directly solving the problems of high development costs, high development difficulty, and wasted human resources.

[0050] To implement the above embodiments, this disclosure also proposes a code generation apparatus for desktop components.

[0051] Figure 2This is a schematic diagram of a code generation device for a desktop component provided in an embodiment of the present disclosure. The device can be implemented by software and / or hardware and is generally integrated into a computing device. Figure 2 As shown, the device includes: The acquisition unit 200 is used to acquire input data, which is used to characterize the functional and / or appearance features of the desktop component to be generated; The input unit 210 is used to input the input data into a pre-trained language transformation model to obtain a component description language, which is used to describe the layout and content of desktop components using a structured syntax. The first generation unit 220 is used to generate code data in the protocol format supported by the target platform according to the component description language and the pre-stored component generation rules of the target platform. The component generation rules of the target platform are a set of mandatory technical specifications for user interface element types, attribute fields, hierarchical structures and data binding in the target platform's custom rendering framework.

[0052] The desktop component code generation apparatus provided in this disclosure can execute the desktop component code generation method provided in any embodiment of this disclosure, and has the corresponding functional modules and beneficial effects of the execution method.

[0053] To implement the above embodiments, this disclosure also proposes a computer program product, including a computer program / instructions, which, when executed by a processor, implements a code generation method for a desktop component in the above embodiments.

[0054] Figure 3 This is a schematic diagram of the structure of a computing device provided in an embodiment of the present disclosure.

[0055] The following is a detailed reference. Figure 3 The diagram illustrates a structural schematic suitable for implementing the computing device 300 in the embodiments of this disclosure. The computing device 300 in the embodiments of this disclosure may include, but is not limited to, mobile terminals such as laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 3 The computing device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0056] like Figure 3As shown, the computing device 300 may include a processor (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 302 or a program loaded from memory 308 into random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the computing device 300. The processor 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0057] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows computing device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 A computing device 300 with various devices is shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0058] 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 309, or installed from a memory 308, or installed from a ROM 302. When the computer program is executed by the processor 301, it performs the functions defined in the code generation method for a desktop component according to embodiments of this disclosure.

[0059] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0060] The aforementioned computer-readable medium may be included in the aforementioned computing device; or it may exist independently and not assembled into the computing device.

[0061] The aforementioned computer-readable medium carries one or more programs, which, when executed by the computing device, cause the computing device to perform the aforementioned method for generating code for a desktop component.

[0062] The computing device can be programmed with computer program code in one or more programming languages ​​or a combination thereof to perform the operations of this disclosure. These programming languages ​​include, but are not limited to, object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0063] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0064] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units are not, in some cases, intended to limit the specific unit.

[0065] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0066] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0067] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0068] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0069] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A code generation method of a desktop component, characterized by, The method comprises: obtaining input data for characterizing a description of functional features and / or appearance features of a desktop component to be generated; inputting the input data into a pre-trained language conversion model to obtain a component description language for describing the desktop component to be generated in a structured syntax; generating code data in a protocol format supported by a target platform according to the component description language and a pre-stored component generation rule of the target platform.

2. The method of claim 1, wherein, The generation of the code data according to the component description language and the component generation rule comprises: converting the component description language into a desktop component layout code file corresponding to an operating system; mapping the desktop component layout code file into the protocol format supported by the target platform according to the component generation rule to generate the code data.

3. The method of claim 2, wherein, The pre-stored component generation rules of multiple platforms are used to map the desktop component layout code file into the protocol format supported by the target platform to generate the code data, which comprises: determining the target platform to be converted from the multiple platforms; mapping the desktop component layout code file into the protocol format supported by the target platform according to the component generation rule of the target platform from the multiple component generation rules to generate the code data.

4. The method of claim 3, wherein, The desktop component layout code file comprises image view component code data and text view component code data, and the mapping of the desktop component layout code file into the protocol format supported by the target platform according to the component generation rule comprises: mapping the image view component code data into image component entry data according to the component generation rule, the image component entry data comprising a component type field, a picture resource reference field and a layout position field; mapping the text view component code data into text component entry data according to the component generation rule, the text component entry data comprising a text content placeholder field, a style field and a position field; combining the image component entry data and the text component entry data according to a hierarchical structure specified in the component generation rule.

5. The method of claim 2, wherein, The method further comprises: presenting a preview interface corresponding to the desktop component to be generated by using the code data.

6. The method of claim 5, wherein, The code data generated is first code data, and the existing desktop component code data is second code data, and the presentation of the preview interface corresponding to the desktop component to be generated by using the code data comprises: extracting data of a target field from the code data; writing the data into image view component code data and text view component code data in the second code data; generating a rendering tree according to the component generation rule; generating placeholder data according to the image view component code data and the text view component code data into which the data is written; writing the placeholder data into a component node in the rendering tree to generate a simulated interface in bitmap form; outputting the simulated interface to an integrated development environment preview window or a separate preview tool to present a preview interface of the desktop component.

7. The method according to any one of claims 1 to 5, characterized in that, The input data is input into a pre-trained language conversion model to obtain a component description language, including: determining user reading habit data; inputting the input data and the user reading habit into a pre-trained language conversion model to obtain a component description language corresponding to the user reading habit.

8. A code generation apparatus of a desktop component, characterized by comprising: including: an acquisition unit, configured to acquire input data, the input data being used to represent a description of a function feature and / or an appearance feature of a desktop component to be generated; an input unit, configured to input the input data into a pre-trained language conversion model to obtain a component description language, the component description language being used to describe a desktop component in a structured syntax; a first generation unit, configured to generate code data in a protocol format supported by a target platform according to the component description language and a component generation rule of the target platform pre-stored.

9. A computing device, comprising: The computing device includes a processor, a memory for storing executable instructions of the processor, and the processor is configured to read the executable instructions from the memory and execute the instructions to implement the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, and the computer program is used to execute the method of any one of claims 1-7.

Images