Graphical design code generation plug-in system

Abstract

A graphical design implementation system provides a design interface to render at least a portion of a graphical design, and provides a code interface to render a code representation of at least a portion of the graphical design. Providing the code interface includes executing one or more plug-ins to generate the code representation, the one or more plug-ins including at least a first plug-in that a user can select to configure generation of the code representation according to one or more preferences.

Description

[0001] Cross-reference to related applications This application claims priority to (i) U.S. Patent Application No. 18 / 748,965, filed June 20, 2024, and (ii) U.S. Provisional Patent Application No. 63 / 522,049, filed June 20, 2023, the full text of which is incorporated herein by reference. Technical Field

[0002] The example described in this article relates to a system for implementing graphical design in a production-ready environment. Background Technology

[0003] Software design tools come in various forms and are widely used. For example, in the field of application user interfaces, software design tools require designers to combine the functional aspects of a program with aesthetics and even legal requirements, ultimately forming a series of pages that constitute the application's user interface. For a specific application, designers often have many goals and requirements that are difficult to track. Attached Figure Description

[0004] Figure 1 The diagram illustrates a system implemented using a graphical design based on one or more examples.

[0005] Figure 2 The diagram illustrates a method for generating a plugin system using graphical design code based on one or more examples.

[0006] Figure 3 The diagram illustrates the example developer mode plugin interface.

[0007] Figure 4 The illustration shows an example of how the developer plugin generates a portion of a graphic design.

[0008] Figure 5 The illustration shows a computer system that can implement one or more embodiments.

[0009] Figure 6 The illustration shows a user computing device used in conjunction with one or more examples as described above. Detailed Implementation

[0010] In the examples, the computing system is configured to implement a Graphic Design Implementation System (GDIS) or platform, enabling users to create various types of content, including graphic designs, whiteboards, presentations, web pages, etc. Among other advantages, as described above, these examples allow users to leverage plugins to extend or supplement the functionality of the Graphic Design Implementation System to meet their specific needs, such as generating a code representation of their graphic designs using a selected programming language.

[0011] Furthermore, the information developers need to correctly implement a design in a production environment may be scattered in many different places: product requirements, design system documents, understanding of existing design aspects in the codebase—this information may be stored in different tools. GDIS's developer plugin can integrate with these other tools, enabling developers to access all relevant information needed to implement the design in one place.

[0012] Code generation is a crucial part of the handover process between graphic designers and developers. However, there are numerous front-end programming languages ​​and popular frameworks, and companies or teams often have different usage guidelines for each language and framework. Unlike conventional methods, the developer plugin system allows developers to generate code for any front-end language, framework, or specification they need. The code generation plugin extends and replaces the built-in code generation functionality provided by GDIS, and can be used to generate code for languages ​​or frameworks not supported by GDIS itself, or to reveal other metadata that users may need (e.g., the location of imported icons or extraction of internationalized strings in the code).

[0013] In some embodiments, the graphical design implementation system provides a design interface for rendering at least a portion of the graphical design, and a code interface for rendering a code representation of at least a portion of the graphical design. Providing the code interface includes executing one or more plugins to generate the code representation, said one or more plugins including at least a first plugin, which a user can select to configure the generation of the code representation according to one or more preferences.

[0014] The one or more embodiments described herein illustrate that the methods, techniques, and operations performed by a computing device are executed in a programmatic manner or as computer-implemented methods. As used herein, "programmatically" means using code or computer-executable instructions. These instructions may be stored in one or more memory resources of the computing device. The steps executed in a programmatic manner may be automatic or non-automatic.

[0015] One or more embodiments described herein may be implemented using program modules, engines, or components. Program modules, engines, or components may include programs, subroutines, portions of programs, software components, or hardware components capable of performing one or more predetermined tasks or functions. As used herein, modules or components may exist independently of other modules or components on hardware components. Alternatively, modules or components may be shared elements or processes of other modules, programs, or machines.

[0016] Some of the embodiments described herein typically require the use of computing devices, including processing and memory resources. For example, one or more embodiments described herein may be implemented wholly or partially on computing devices such as servers, desktop computers, cellular networks or smartphones, tablets, wearable electronic devices, laptops, printers, digital photo frames, network devices (e.g., routers), and tablet devices. Memory, processing, and network resources may be used in conjunction with building, using, or performing any of the embodiments described herein, including performing any methods or implementing any system.

[0017] Furthermore, one or more aspects described herein may be implemented by one or more processor-executable instructions. These instructions may be stored on a computer-readable medium. The machines shown or described in the figures below provide examples of processing resources and computer-readable media for storing and / or executing instructions that implement certain aspects. Specifically, the numerous machines shown or described include processors and various forms of memory for storing data and instructions. Examples of computer-readable media include persistent storage devices, such as hard drives in personal computers or servers. Examples of other computer storage media include portable storage units, such as CD or DVD devices, flash or solid-state memory (e.g., memory used in mobile phones, tablets, and other consumer electronic devices), and magnetic storage. Computers, terminals, and network-enabled devices (e.g., mobile devices such as mobile phones) are examples of machines and devices that utilize processors, memory, and instructions stored on computer-readable media.

[0018] Alternatively, one or more examples described herein can be implemented using dedicated hardware logic circuitry composed of interconnected logic gates. Such circuitry is typically designed using hardware description languages ​​(HDLs) such as Verilog and VHDL. These languages ​​contain instructions that ultimately define the circuit layout. However, once the circuit is fabricated, the instructions no longer exist, and processing is performed by the interconnected logic gates.

[0019] System Description Figure 1 The diagram illustrates a system implemented using a graphical design based on one or more examples. For example, using... Figure 1The described Graphical Design Implementation System 100 (“GDIS 100”) can be implemented in any of a variety of different computing environments, including as a device-side application, a network service, and / or a collaboration platform. For example, GDIS 100 can be implemented using a web-based application 80 running on user device 10. In other examples, GDIS 100 can be implemented using a dedicated web-based application. As a complement or alternative, one or more components of GDIS 100 can be implemented as a distributed system, such that the processes described using the various examples can execute either on a network computer (e.g., a server) or on user device 10.

[0020] In some examples, GDIS 100 includes processes executed by a web-based application 80 installed on computing device 10. The web-based application 80 can execute scripts, code, and / or other logic to implement the functionality of GDIS 100. Furthermore, in some variations, GDIS 100 can be implemented as part of a network service, where the web-based application 80 communicates with one or more remote computers (e.g., servers for the network service) to execute processes of GDIS 100.

[0021] In some examples, user device 10 includes a web-based application 80 that loads processes and data to provide GDIS 100 on user device 10. GDIS 100 may include: a design interface 130 that enables users to create, edit, and update graphic design files; and a rendering engine 120 for reading graphic design files and displaying them on the design interface 130.

[0022] In some examples, the web-based application 80 retrieves program resources for implementing GDIS 100 from a website. As a supplement or alternative, the web-based application 80 may retrieve some or all of the program resources from a local source (e.g., local storage located on computing device 10). The web-based application 80 may also access various types of datasets to provide functionality similar to that described in GDIS 100. These datasets may correspond to files and libraries, which may be stored remotely (e.g., on a server, associated with an account) or locally.

[0023] According to the example, user device 10 uses web-based application 80 to access a website, where it retrieves and executes program resources to implement GDIS 100. The user can initiate a session to implement GDIS 100 to view, create, and edit graphic designs, as well as generate program code for implementing those designs in a production environment. In some examples, the user may be the designer, responsible for creating, editing, and refining the graphic design for later use in production. In other examples, the user may correspond to the developer, responsible for accessing the graphic design to retrieve the corresponding resources and program code for later use in production.

[0024] In the examples, the web-based application 80 can correspond to a commercially available browser, such as Google Chrome (developed by Google), Safari (developed by Apple), or Edge (developed by Microsoft). In these examples, the processes of GDIS 100 can be implemented as scripts and / or other embedded code, which the web-based application 80 can download from a website. For example, the web-based application 80 can execute code embedded in a webpage to implement the processes of GDIS 100. The web-based application 80 can also execute scripts to retrieve other scripts and program resources (e.g., libraries) from websites and / or other local or remote locations. By way of example, the web-based application 80 can execute JavaScript embedded in HTML resources (e.g., webpages built according to HTML 5.0 or other versions based on standards published by the W3C or WHATWG consortium). In other variations, GDIS 80 can be implemented using a dedicated application (e.g., a web-based application).

[0025] GDIS 100 may include processes represented by program interface 102, rendering engine 120, design interface 130, code interface 132, and code generator 140. Depending on the implementation, these components may execute on user device 10, on network system (e.g., server or server combination), or on user device 10 and network system (e.g., as distributed processes).

[0026] Program interface 102 includes processes for receiving and sending data to implement components of GDIS 100. Furthermore, program interface 102 can be used to retrieve program resources and datasets from local or remote sources, including workspace files 155 associated with a user or user account. In an example, workspace file 155 contains one or more datasets (represented by graphic design datasets 157) that represent corresponding graphic designs that can be rendered by rendering engine 120. Workspace file 155 may contain one or more graphic design datasets 157 that collectively define the design interface. Graphic design datasets 157 may be structured as one or more hierarchical data structures. In some examples, graphic design datasets 157 may be structured to define graphic designs as a collection of layers, where each layer corresponds to an object, a group of objects, or an object of a specific type. Additionally, in some examples, graphic design datasets 157 may be organized to contain graphic designs on a screen, where each graphic design contains one or more pages (e.g., each page has a canvas), or segments containing one or more pages.

[0027] According to one aspect, program interface 102 also retrieves program resources, including an application framework for implementing design interface 130. Design interface 130 can utilize a combination of local resources, browser-based resources, and / or web resources (e.g., application frameworks) provided through program interface 102 to generate interactive functions and tools that can be integrated with the rendering of graphic designs on a canvas. The application framework enables users to view and edit various aspects of the graphic design. In this way, design interface 130 can be implemented as a functional layer integrated with a canvas providing the graphic design.

[0028] Design interface 130 can detect and interpret user input, for example, based on the location and / or type of the input. The location of the input can refer to a canvas or screen location, such as a tap, or the start and / or end location of continuous input. The input type can correspond to one or more types of input occurring on the canvas, or design elements rendered on the canvas. These inputs can be associated with canvas or screen locations to select and manipulate design elements or portions thereof. Based on the canvas or screen location, user input can also be interpreted as input for selecting design tools, such as those provided by the application framework. In an implementation, design interface 130 can use a reference to the corresponding canvas to identify the screen location of the user input (e.g., a "click"). In addition, the design interface 130 can interpret user input actions based on the detected input location (e.g., whether the input location indicates a selection of a tool, an object rendered on the canvas, or a canvas area), the frequency of input detected within a given time period (e.g., double-click), and / or the start and end positions of an input or a series of inputs (e.g., the start and end positions of a click and drag), as well as various other input types that the user may specify through one or more input devices (e.g., right-click, screen tap, etc.).

[0029] In some examples, rendering engine 120 and / or other components utilize graphics processing unit (GPU) accelerated logic, such as logic provided by WebGL (Web Graphics Library) programs that execute Graphics Library Shader Language (GLSL) programs running on the GPU. In other variations, web-based application 80 may be implemented as a dedicated web-based application optimized to provide the functionality described in the various examples. Furthermore, web-based application 80 may vary depending on the type of user device, including the operating system used by user device 10 and / or the form factor of the user device (e.g., desktop computer, tablet, mobile device, etc.).

[0030] For example, rendering engine 120 uses graphic design dataset 157 to generate a rendered image of graphic design rendering 135 for design interface 130, where the rendering of graphic design 135 includes graphic elements, attributes, and attribute values. Each attribute of a graphic element can include an attribute type and an attribute value. For objects, attribute types include shape, size (or dimensions), layer, type, color, line thickness, text size, text color, font, and / or other visual characteristics. Depending on the implementation, these attributes reflect the nature of the two-dimensional or three-dimensional design. Thus, the attribute values ​​of individual objects can define, for example, the size, color, positioning, layering, and content visual characteristics of elements rendered as part of the design.

[0031] Graphic design 135 can be organized by screen (e.g., a computer screen representing a production environment), page (e.g., where each page contains a canvas on which the corresponding graphic design is rendered), and section (e.g., where each screen contains multiple pages or screens). Users can interact with the rendered result of the graphic design via design interface 130 to view and edit the graphic design. Design interface 130 can detect user input, and rendering engine 120 can update graphic design 135 in response to the input. For example, a user can specify input to change the view of graphic design 135 (e.g., zoom in or out), and in response, rendering engine 120 updates graphic design 135 to reflect the change in view. Users can also edit the graphic design. Design interface 130 can detect input, and rendering engine 120 can update graphic design dataset 157 representing the updated design. Furthermore, rendering engine 120 can update graphic design 135 of the graphic design, allowing users to immediately see the changes to graphic design 135 resulting from user interaction.

[0032] Collaborative Environment In the example, GDIS 100 can be implemented as part of a collaboration platform where multiple users can operate computer devices at different locations to view and edit graphic designs. As part of the collaboration platform, when a user edits a graphic design, the changes made by the user are implemented in real time on instances of the graphic design on the computer devices of other collaborating users. Similarly, when other collaborators make changes to the graphic design, these changes are also reflected in the graphic design dataset 157 in real time. The rendering engine 120 can update the graphic design 135 in real time to reflect the changes made to the graphic design by the collaborators.

[0033] In the implementation, when the rendering engine 120 makes changes to the graphic design dataset 157, it can transmit the corresponding change data 111 representing that change to the network system 150. The network system 150 can implement one or more synchronization processes (represented by the synchronization component 152) to maintain the network-side representation of the graphic design. In response to receiving change data 111 from user device 10, the network system 150 updates the network-side representation of the graphic design and transmits the change data 111 to the user devices of other collaborators. Similarly, if another collaborator makes changes to the graphic design instance on their respective device, the corresponding change data 111 can be transmitted from the collaborator's device to the network system 150. The synchronization component 152 updates the network-side representation of the graphic design and transmits the corresponding change data 111 to user device 10 to update the graphic design dataset 157. Then, the rendering engine 120 updates the graphic representation 135 of the graphic design.

[0034] Code generation For example, GDIS 100 includes a process, represented by code generation 140, for generating code data for a code representation 145 of a graphic design. Code generation component 140 may include a process for accessing a graphic design dataset 157 in a workspace file 155 and generating code data representing elements of the graphic design. The generated code data may include production-executable instructions (e.g., JavaScript, Python, Ruby, etc.) and / or information describing the layout or style of the graphic design (e.g., HTML, CSS, etc.).

[0035] In some examples, the graphic design dataset 157 is structured to define multiple layers, each corresponding to an object, a group of objects, or an object of a specific type. In specific examples, layer types may include frame objects, a group of objects, components (i.e., objects composed of multiple objects reflecting state or other changes between instances), text objects, images, configuration logic (for implementing layout or positional links between multiple objects), and other predefined element types. For each layer of the graphic design, the code generation component 140 generates a set of code data associated with or otherwise linked to that design element. For example, each layer of the graphic design dataset 157 may contain an identifier, and the code generation component 140 may generate a set of code data associated with the identifier for each layer. The code generation component 140 may generate a code representation 145 such that elements of the code representation 145 (e.g., layout information, executable instruction sets, etc.) are associated with specific layers of the graphic design 135. These associations map the individual code elements of the code representation 145 to the corresponding design elements (or layers) of the graphic design 135 (represented by the graphic design dataset 157).

[0036] In some examples, code interface 132 renders an ordered representation of code representation 145. For instance, code interface 132 may divide the representation area into separate regions, including separate fragments for displaying production-ready executable code instructions (e.g., separate regions for HTML and CSS code). Furthermore, code interface 132 may contain separate fragments for identifying assets used in the graphic design, such as design elements that are part of a library associated with a user-associated account library.

[0037] Code interface 132 can implement a combination of local resources, browser-based resources, and / or web resources (e.g., application frameworks) provided by program interface 102 to generate a set of interactive functions and tools for displaying code representation 145. For example, code interface 132 can make individual elements of code representation 145 selectable as input. For example, a user can select one or more of the following as input: (i) a line of code; (ii) a portion of a line of code corresponding to a certain attribute; or (iii) a portion of a line of code reflecting a certain attribute value. In addition, the user can also select program code data to be displayed in different areas, different types of program code (e.g., HTML or CSS), assets, and other program data elements.

[0038] Plug-in system In the described embodiments, a plugin may correspond to a program that can be executed on end-user device 10 to provide additional or enhanced functionality to GDIS 100. For example, a designer may execute the plugin in conjunction with GDIS 100 to create or update designs. Furthermore, a developer may execute the plugin to generate a code representation 145 of one or more elements in a graphic design.

[0039] In the example, the plugin repository 165 contains program files (e.g., executable files) that can be executed according to the end-user's selection, allowing the end-user to create and / or update designs on a canvas using the GDIS 100. Plugins can be created by developers, including third-party developers of GDIS 100. In the example, each plugin can be selectively executed by the user to achieve a process independent of GDIS 100 functionality. Therefore, plugins stored in the plugin repository 165 can provide additional or enhanced functionality for use with the GDIS 100. This functionality can include developer-mode plugins that the code generation component 140 can utilize to generate code representation 145.

[0040] For example, a developer can interact with the plugin system 160 to store plugin files (or a set of files used at runtime) along with the plugin repository 165. Plugin files may include one or more executable files of the plugin and plugin execution logic. Plugin execution logic may contain code, programs, programmatic processes, and / or data, which can be accessed by the plugin system 160. In some implementations, plugin execution logic includes metadata specified by the developer, which contains parameter values ​​related to the plugin input provided by the user when executing the plugin.

[0041] Code generation plugin for developers By using developer plugin 142, code generation component 140 can generate code representation 145 based on one or more user preferences, such as selecting a programming language or framework supported by the developer plugin 142. In some cases, developers or third parties may create developer plugin 142 and store it in plugin repository 165 along with GDIS 100. For example, a developer may access network system 150, search for developer plugin 142 that supports a programming language compatible with the developer's production environment, and download it to plugin repository 165. Alternatively, developers can use tools to create developer plugin 142 compatible with GDIS 100.

[0042] In one implementation, the developer code generation plugin includes a manifest field that allows the plugin to define custom preferences. These preferences allow plugin users to customize the developer code generation output and are available to the plugin via an Application Programming Interface (API). Developer code generation preferences allow developers to define custom commands for the plugin, which are displayed in the native dropdown settings interface for developer code generation. For example, one of these preferences includes a list of supported programming languages ​​for developer code generation in the local language selector dropdown menu of GDIS 100 developer mode. Among these commands, plugin code can be executed, including the ability to open an iFrame on code interface 132.

[0043] Therefore, when using developer plugin 142, users can select one of the supported programming languages ​​from a list included with developer plugin 142. Developer code generation preferences may also include links to external repositories 143. To correctly implement the graphical design in a production environment, developer plugin 142 can integrate with external repositories 143 to extract relevant information needed to implement the design. For example, developer plugin 142 can access a remote Git repository to retrieve code used by code generation component 140 to enhance code representation 145.

[0044] In some examples, developer plugins 142 are read-only, meaning they can use the plugin API to read data from the design workspace file 155. They can respond to API events (e.g., change data 111 received from the network system 150), make network requests, or open iFrames to create or modify the user interface; however, they cannot edit the contents of file 155. This is because developers typically do not have editing permissions for workspace file 155. Therefore, developer plugins 142 can access workspace file 155, listen for events, and make network requests, but cannot modify workspace file 155 in any way. Therefore, any method or operation that creates new nodes, deletes existing nodes, or modifies existing nodes is not allowed.

[0045] In some respects, developer plugin 142 can call `node.isAsset`, an API that returns whether a given node is an asset. As used herein, an asset refers to a design element such as an icon or raster image. GDIS 100 uses a refined set of heuristics to determine assets, but generally, icons are small vector graphics, while images are nodes with image fills. The `node.isAsset` function returns true if a node is determined to be an asset, and false otherwise. The `node.isAsset` function can be used to display nodes that developers can export, or to present an image URL or Scalable Vector Graphics (SVG) instead of application code when generating code. Therefore, developer plugin 142 can enable code interface 132 to identify whether a node is an asset as part of code representation 145.

[0046] In some respects, Developer Plugin 142 can infer layout rules within one or more layers of a graphic design. Developer Plugin 142 can define `node.inferredAutoLayout`, a property used to determine the auto-layout properties of a FrameNode, even if the frame is not configured for auto-layout. If GDIS 100 can infer auto-layout, the `node.inferredAutoLayout` property returns an object containing a subset of the auto-layout properties typically present on the Frame node. Auto-layout properties can include spatial relationships between multiple layers of the graphic design. If GDIS 100 cannot infer auto-layout, it returns null. In some respects, Developer Plugin 142 can define `node.getCSSAsync`, which returns an object that resolves to key / value pairs of CSS properties. Developer Plugin 142 can then use these CSS property key / value pairs as part of a conversion process to other programming languages. For example, Developer Plugin 142 for the styled-components React library can leverage CSS key / value pairs to accelerate development.

[0047] In some respects, developer plugin 142 can define a `getSelectionColors` function that returns the color currently selected by the user. The value it returns is the same as the value displayed in the native color selection functionality. This is very useful for obtaining a list of colors and styles currently selected and converting it into different code formats (such as CSS variables in the user's codebase).

[0048] In some examples of GDIS 100's developer mode, only one object can be selected at a time to simplify navigation and inspection. Developer mode panels (such as the one with code interface 132) can contain simplified views of properties, code, and assets. If the developer mode plugin contains an iFrame, that iFrame can be docked in a new tab by default. This ensures that the plugin's iFrame does not obscure any part of design interface 130 or the content that the developer needs to implement.

[0049] Code Editor Extension In addition to enhancing the functionality of GDIS 100 itself, or as an alternative to enhancing the functionality of GDIS 100, the plug-in system 160 can also run within an extension of a third-party code editor (such as Visual Studio Code). Such an extension allows the third-party code editor to display the design interface 130 and / or the code interface 132 within the code editor, thereby allowing the user to interact with the workspace file 155 and the code representation 145 from within the code editor.

[0050] In some respects, the code editor extension provides autocomplete suggestions to the user based on the selected layer of the graphical design 135 within the code editor. These autocomplete suggestions may be generated by one of the developer plugins 142. For example, the user can select one of the developer plugins 142 from the list of plugins within the extension, and then, when the autocomplete function is activated, suggestions can be generated using the selected developer plugin 142, rather than the default suggestion source or as a supplement to the default suggestion source.

[0051] Plugin Preview In some respects, the plugin system 160 supports a preview function that triggers the execution of a specific plugin when a developer or designer adds a relevant link to a design resource (such as workspace file 155). This function allows for the generation of rich previews associated with the linked content. For example, when a user inserts a link corresponding to a supported plugin (such as a GitHub, JIRA, or Linear plugin), GDIS 100 recognizes the link (e.g., a URL) and runs the appropriate plugin in the background. The process performed by GDIS 100 when recognizing a link may include searching the plugin repository for a plugin identifier that matches the link. Furthermore, the process performed by GDIS 100 when recognizing an inserted link and running the appropriate plugin can be automated. The plugin retrieves details and generates a preview, which is displayed in a side panel within the design interface 130.

[0052] The preview generation process may include user authentication if necessary to access more detailed information related to the link. The plugin's output (such as task details from a project management tool, e.g., from one or more external repositories 143) can be saved as part of the workspace file 155. For example, the plugin output can be saved as a JSON text representation or any other context-appropriate format. This ensures that when the workspace file 155 is shared with other collaborators, GDIS 100 can display a pre-generated preview after one of them opens the workspace file 155, without having to rerun the plugin or go through additional authentication steps.

[0053] The design environment efficiently handles plugin execution triggered by link insertions, designed to improve workflow. The plugin system 160 automates this process, eliminating the need for users to manually select and run plugins, thereby increasing productivity and ensuring consistency across shared workspace files 155. By leveraging OAuth flows, plugins can retrieve comprehensive data, enabling richer and more functional previews. This integration framework is scalable to support various types of links and plugins, providing a flexible solution for embedding interactive and informative elements in design resources.

[0054] Select the code to view design elements. Code interface 132 can detect user input to select a code element. In response to detecting user input for a specific code element, code interface 132 can identify and pass the associated design element (or layer) to design interface 130. For example, code interface 132 can identify a specific layer indicated by the user's selection input. Code interface 132 can indicate the identified layer or design element to design interface 130, thereby causing design interface 130 to highlight or emphasize the design element associated with the selected code element. In some examples, design interface 130 can visually isolate or separate the design element associated with the code element selected through code interface 132 from other elements of the graphic design. In this case, other design elements in the graphic design can be hidden, while the associated design element is displayed in the window of design interface 130. In this way, when the user interacts with code interface 132, the user can easily distinguish the associated design element from other elements of the graphic design.

[0055] In developer mode, developer plugin 142 calls the generation function to register a callback function that is invoked when the user changes layer selections in the graphical design. This callback function returns an internal representation of the selected layer. For example, the internal representation is an array of JavaScript objects that represent various sections in the inspection panel. Each JavaScript object can contain code, language, and title properties. If the function is asynchronous and requires data fetching or other asynchronous operations to generate the code for the selected layer, the callback function can also return an object representing the current operation state.

[0056] In some respects, developer plugin 142 translates the internal representation into a user-selected programming language. For example, JavaScript objects can be parsed and used to generate equivalent HTML and CSS for rendering graphic designs in a production environment. The generated HTML and CSS are displayed on code interface 132, where users can copy and paste lines of code (along with any additional data retrieved and processed from external repository 143) into a separate development environment to implement the graphic design in production.

[0057] Select the code to navigate to the design elements. Furthermore, selecting a code element in code interface 132 allows design interface 130 to navigate to a specific set of design elements identified by the selected code element. For example, code element 132 may identify a layer selected by user input, and design interface 130 may navigate the view of graphic design 135 to a canvas location that provides the associated design element. As a supplement or variation, design interface 130 may navigate by changing the zoom level of the view, thereby focusing on a specific design element associated with the identified design element.

[0058] Synchronous design of interfaces and code interfaces In the example, the design interface and code interface 132 can be synchronized regarding the content displayed through each interface. For example, code interface 132 can be provided as a window displayed side-by-side with or simultaneously with the design interface window. In one aspect, code interface 132 displays code elements that form part of the code representation, where each code element is associated with a layer or design element having a corresponding identifier. In turn, design interface 130 uses the identifier of the layer / design element to render design elements in the graphical design 135 that are consistent with the code elements displayed by code interface 132.

[0059] Furthermore, GDIS 100 can implement processes that link the content of design interface 130 with the content of code interface 132. For example, if a user scrolls through code data displayed via code interface 132, design interface 130 can navigate the rendering of graphic design 135 or center the rendering of graphic design 135 to reflect the code elements visible in code interface 132. As previously mentioned, design interface 130 and code interface 132 can use the set of public identifiers for layers or design elements provided by graphic design dataset 157.

[0060] Modify graphic design via code interface For example, user device 10 can modify the graphic design 135 by modifying the code representation using code interface 145. For instance, a user can select a code element displayed through code interface 132 and then change the attributes, attribute values, or other aspects of that code element. Input can identify and modify layers or design elements defined in the structure defined by the graphic design dataset 157. In response, rendering engine 120 can update the rendering of graphic design 135 to reflect the changes made through code interface 132. In this way, developers can modify, for example, the design interface in real time, to add, remove, or otherwise modify (e.g., by changing attributes or attribute values) layers or design elements.

[0061] View and modify code elements through the design interface. Furthermore, in the example, a user can select design elements in a graphic design by interacting with design interface 130. For example, a user can select or modify a layer in the graphic design. Design interface 130 can identify this layer for code interface 132. In response, code interface 132 can highlight or otherwise distinguish the code element (e.g., a line of code) associated with the identified design element from the rest of the code representation 145. In this way, developers can easily examine the code elements generated for design elements of interest by selecting a design element or the layer corresponding to that design element in design interface 130 and then viewing the code generated for the selected element or layer in code interface 132.

[0062] Furthermore, in the example, a user can edit the graphic design 135 by interacting with the design interface 130. The rendering engine 120 can respond to input by updating the graphic design 135 and the graphic design dataset 157. When the graphic design dataset 157 is updated, the code generation component 140 can update the code representation 145 to reflect the changes. Additionally, the code interface 132 can highlight, emphasize, or otherwise visually indicate code elements that have changed due to modifications made to the graphic design 135 via the design interface 130.

[0063] Code generation to reflect changes in the design interface. In an additional example, a change detection component can identify changes in graphic design 135, and these changes can be indicated in graphic design dataset 157 and code representation 145. For example, in a collaborative environment, graphic design dataset 157 may change between user sessions of device 10 due to work done by other collaborators. In the example, design interface 130 can indicate design elements in the graphic design that have changed compared to a previous point in time (e.g., between user sessions).

[0064] For example, code generation component 140 can generate code to update code representation 145 based on a changed dataset. Code interface 132 can indicate code elements in the graphic design that have been added or modified relative to previous user sessions. This allows designers to see what has changed between graphic designs. Similarly, developers can see corresponding changes to code representation 145, which may be the result of changes made by the graphic design designer.

[0065] Figure 2 The diagram illustrates a method for generating a plug-in system using graphical design code based on one or more examples. Some steps of this method may be performed in parallel, or they may be performed in a different order than shown in the diagram.

[0066] In one example, a computer system (e.g.) Figure 1The GDIS 100 provides a design interface for rendering graphic designs (210). The graphic design can be represented by one or more workspace files 155 and rendered by the rendering engine 120 on the design interface 130 of the GDIS 100.

[0067] The computer system can receive a selection of developer plugins from the user (220). This selection can be made on the program interface 102 of the GDIS100.

[0068] The computer system can receive selections of preferences, including the programming language associated with the developer plugin (230). The computer system can use the developer plugin to generate and render a code representation 145 (240) of the graphic design on the code interface 132.

[0069] Example Figure 3 The illustration shows an example of a developer mode plugin interface. Developer code generation plugins can extend and / or replace the built-in code generation functionality present in the inspection panel 300. As shown, the iOS and Android code generation options in the inspection mode menu 310 are built-in options marked "(Legacy)", while other options are provided by the developer code generation plugin for generating code for languages ​​and frameworks not supported by the graphical design system itself. In this example, the language selected in the inspection mode menu 310 is "i18n Strings", an internationalization framework written in and for JavaScript. Therefore, when the user selects an object, the code generation component uses the developer plugin "i18n Strings" to generate the i18next string for display in the code interface 320.

[0070] Figure 4 The illustration shows an example of generating a portion of a graphic design using a developer plugin. (Continued) Figure 3 In the example, the user selects Frame 1 object 430 containing a pair of strings. When developing applications, developers often need to extract strings to build an internationalized dictionary. Therefore, the "i18n Strings" plugin example retrieves the text nodes 431 and 432 under the current selection and builds their JSON dictionary, which is displayed in the code interface 420 of the right-hand inspection panel 400.

[0071] Network computer system Figure 5 The illustration depicts a computer system that can implement one or more embodiments. Computer system 500 can be implemented, for example, on a single server or a combination of multiple servers. For example, computer system 500 can be implemented as... Figure 1The network computing system 150 in the middle.

[0072] In one embodiment, computer system 500 includes processing resources 510, memory resources 520 (e.g., read-only memory (ROM) or random access memory (RAM)), one or more instruction memory resources 540, and a communication interface 550. Computer system 500 includes at least one processor 510 for processing information stored in memory resources 520, such as information provided by random access memory (RAM) or other dynamic storage devices for storing information and instructions executable by processor 510. Memory resources 520 can also be used to store temporary variables or other intermediate information during instruction execution by processor 510.

[0073] Communication interface 550 enables computer system 500 to communicate with one or more user computing devices via one or more networks (e.g., cellular networks) using network link 580 (wireless or wired). Using network link 580, computer system 500 can communicate with one or more computing devices, dedicated devices and modules, and / or one or more servers.

[0074] For example, processor 510 can execute service instructions 522 stored using memory resources 520 to enable the network computing system to implement network service 172 and operate as network computing system 170, for example in Figure 1 A to Figure 1 As in the example described in C.

[0075] Computer system 500 may also include additional memory resources (“instruction memory 540”) for storing executable instruction sets (“Int.sys.instr. 545”) embedded in web pages and other network resources, enabling user computing devices to perform functions such as those described in GDIS 100.

[0076] Therefore, the examples described herein relate to implementing the techniques described herein using a computer system 500. According to one aspect, the computer system 500 implements the techniques in response to processor 510 executing one or more sequences of one or more instructions contained in memory 520. These instructions may be read into memory 520 from other machine-readable media. Executing the sequence of instructions contained in memory 520 causes processor 510 to perform the processing steps described herein. In alternative implementations, hardwired circuitry may be used instead of or in combination with software instructions to implement the examples described herein. Therefore, the described examples are not limited to any particular combination of hardware circuitry and software.

[0077] User computing devices Figure 6 The illustration depicts user computing devices for one or more examples, as described above. In the examples, user computing device 600 may correspond to, for example, a workstation, desktop computer, laptop computer, or other computer system with graphics processing capabilities suitable for rendering design interfaces and performing graphic design work. In some variations, user computing device 600 may correspond to mobile computing devices such as smartphones, tablets, laptops, VR or AR headsets, etc.

[0078] For example, computing device 600 includes a central processing unit or main processor 610, a graphics processing unit 612, memory resources 620, and one or more communication ports 630. Computing device 600 can use the main processor 610 and memory resources 620 to store and launch a browser 625 or other web-based applications. A user can use communication port 630 to operate browser 625 to access network system 150, thereby downloading one or more web pages or other resources 605 associated with network system 150. These web resources 605 can be stored in active memory 624 (cache).

[0079] As described in various examples, processor 610 can detect and execute scripts and other logic embedded in web resources to implement GDIS 100 (see...). Figure 1 In some examples, certain scripts 615 embedded in Web resource 605 may contain GPU-accelerated logic that is executed directly by GPU 612. The main processor 610 and the GPU can work together to render the design interface being edited (“DIUE 611”) on display component 640. The rendered design interface may contain web content from browser 625, as well as design interface content and functional elements generated by scripts and other logic embedded in Web resource 605. As described in various examples, by including scripts 615 that can be executed directly on GPU 612, the logic embedded in Web resource 615 can better perform GDIS 100.

[0080] in conclusion While examples have been described in detail herein with reference to the accompanying drawings, it should be understood that these concepts are not limited to these specific examples. Therefore, the scope of these concepts is intended to be defined by the following claims and their equivalents. Furthermore, it is contemplated that a particular feature described separately or as part of an example may be combined with other separately described features or portions of other examples, even if the other features and examples do not mention that particular feature. Therefore, the absence of a described combination should not preclude the right to that combination.

Claims

1. A computer system, comprising: Memory resources, wherein the memory resources store instructions; as well as One or more processors, the one or more processors using instructions stored in the memory resource to perform operations, the operations including: Provide a design interface to render at least a portion of the graphic design; as well as A code interface is provided to render a code representation of at least a portion of the graphical design, wherein providing the code interface includes executing one or more plugins to generate the code representation, the one or more plugins including at least a first plugin, which a user can select to configure the generation of the code representation according to one or more preferences.

2. The computer system as claimed in claim 1, wherein, The first plugin supports multiple programming languages ​​for code representation.

3. The computer system as described in claim 2, wherein, The one or more preferences include selecting a first programming language from the plurality of programming languages.

4. The computer system as described in claim 3, wherein, The first plugin converts at least a portion of the internal representation of the graphic design into the first programming language, which is different from the internal representation.

5. The computer system as claimed in claim 1, wherein, The first plugin retrieves data from one or more external repositories and integrates the data into the code representation.

6. The computer system as claimed in claim 1, wherein, The graphic design is structured to define multiple layers, each of which corresponds to one of an object, a group of objects, or an object of a certain type. and The execution of one or more plugins is performed in response to the user selecting one of the multiple layers using either the design interface or the code interface.

7. The computer system as claimed in claim 1, wherein, Executing one or more plugins includes enabling the code interface to recognize assets that are part of the code representation.

8. The computer system as claimed in claim 4, wherein, Executing the one or more plugins includes inferring layout rules within one or more layers of the graphic design.

9. The computer system as claimed in claim 8, wherein, The layout rules specify the spatial relationships between multiple layers of the graphic design.

10. The computer system of claim 8, wherein, The layout rules specify the spacing between multiple layers of the graphic design.

11. The computer system as claimed in claim 1, wherein, The first plugin is a third-party plugin.

12. The computer system as claimed in claim 1, wherein, The first plugin has read-only access to the graphic design.

13. A method implemented by one or more processors, the method comprising: Provide a design interface to render at least a portion of the graphic design; as well as A code interface is provided to render a code representation of at least a portion of the graphical design, wherein providing the code interface includes executing one or more plugins to generate the code representation, the one or more plugins including at least a first plugin that a user can select to configure the generation of the code representation according to one or more preferences.

14. The method of claim 13, wherein, The first plugin supports multiple programming languages ​​for code representation.

15. The method of claim 14, wherein, The one or more preferences include selecting a first programming language from the plurality of programming languages.

16. The method of claim 15, wherein, The first plugin converts at least a portion of the internal representation of the graphic design into the first programming language, which is different from the internal representation.

17. The method of claim 13, wherein, The first plugin retrieves data from one or more external repositories and integrates the data into the code representation.

18. The method of claim 13, wherein, The graphic design is structured to define multiple layers, each of which corresponds to one of an object, a group of objects, or an object of a certain type. and The execution of one or more plugins is performed in response to the user selecting one of the multiple layers using either the design interface or the code interface.

19. The method of claim 13, wherein, Executing one or more plugins includes enabling the code interface to recognize assets that are part of the code representation.

20. A non-transitory computer-readable medium storing instructions executable by one or more processors to cause the one or more processors to perform operations, the operations comprising: Provide a design interface to render at least a portion of the graphic design; as well as A code interface is provided to render a code representation of at least a portion of the graphical design, wherein providing the code interface includes executing one or more plugins to generate the code representation, the one or more plugins including at least a first plugin, which a user can select to configure the generation of the code representation according to one or more preferences.

Images