Cross-platform middleware for vehicle-mounted graphical interface generation

Abstract

The invention discloses cross-platform middleware generated by a vehicle-mounted graphical interface. The cross-platform middleware is characterized in that an automatic interface generation module binds element controls with corresponding names and attribute information according to widgets.json; the automatic menu generation module is used for binding each menu item control with a menu name, a menu index and corresponding attribute information according to the menus.json file; the multi-language translation module determines multi-language translation information according to the json file; performing event response packaging on each element control and each menu item control by a message event processing mechanism; and the GUI graphics library API interface performs graphic rendering of the vehicle-mounted instrument interface on each element control and each menu item control based on the multi-language translation information and the event response packaging result. According to the method, the json file with the complete graphical interface information is generated into the complete graphical interface according to the cooperation among the independent modules, so that the development process is simplified, and the development efficiency is improved.

Description

Technical Field

[0001] The invention relates to the technical field of vehicle-mounted instrument development, and in particular to a cross-platform middleware for generating a vehicle-mounted graphical interface. Background Art

[0002] In the modern automobile industry, in-vehicle LCD instruments have gradually become standard equipment for modern cars, taking on multiple tasks such as information display, function control and user interaction. The complexity and diversity of in-vehicle graphical interfaces are also increasing. Traditional development methods often require a lot of manual coding and cumbersome configuration, which is time-consuming and labor-intensive, prone to errors, and difficult to meet the needs of rapid iteration and personalized customization. In particular, in the face of different requirements for interface functions and languages ​​for different models and markets, developers need to spend a lot of time on repetitive work, which reduces development efficiency. Therefore, how to improve the development efficiency of in-vehicle instruments has become an urgent problem to be solved.

[0003] The above contents are only used to assist in understanding the technical solution of the present invention and do not constitute an admission that the above contents are prior art. Summary of the invention

[0004] The main purpose of the present invention is to provide a cross-platform middleware for generating a vehicle-mounted graphical interface, aiming to solve the problem of how to improve the development efficiency of vehicle-mounted instruments.

[0005] To achieve the above-mentioned object, the present invention provides a cross-platform middleware for generating a vehicle-mounted graphical interface, wherein the cross-platform middleware for generating a vehicle-mounted graphical interface comprises an interface automatic generation module, a menu automatic generation module, a message event processing mechanism, a multi-language translation module, and a GUI graphics library API interface;

[0006] The automatic interface generation module is used to perform data binding of each element control with the corresponding name and attribute information according to the widgets.json file of the vehicle instrument interface;

[0007] The menu automatic generation module is used to perform data binding on each menu item control with the menu name, the menu index and the corresponding attribute information according to the menu.json file of the vehicle instrument interface;

[0008] The multilingual translation module is used to determine multilingual translation information according to the widgets.json file and the menus.json file;

[0009] The message event processing mechanism is used to encapsulate control event responses for each element control and each menu item control;

[0010] The GUI graphics library API interface is used to perform graphics rendering of the vehicle instrument interface for each element control and each menu item control based on the multi-language translation information and the control event response encapsulation result.

[0011] Optionally, the automatic interface generation module is used to read the widgets.json file of the vehicle instrument interface, obtain multiple element control information, and save the multiple element control information into the widget_items linked list array;

[0012] The automatic interface generation module is also used to parse the information of each element control in sequence based on the widget_items linked list array to obtain the name of each element control and the attribute information of each element control. There is a one-to-one correspondence between the name of the element control and the attribute information of the element control.

[0013] Optionally, the automatic interface generation module is further used to perform data binding on each element control to be rendered and the corresponding name and attribute information in the widget_items linked list array;

[0014] The automatic interface generation module is also used to call the GUI graphics library API interface to perform element graphics rendering on each element control to be rendered through an interface element mapping mechanism after data binding is completed.

[0015] Optionally, the menu automatic generation module is used to read the menu.json file of the vehicle instrument interface, obtain multiple menu item control information, and save the multiple menu item control information into the menu_items linked list array;

[0016] The menu automatic generation module is also used to parse the control information of each menu item in sequence based on the menu_items linked list array to obtain the menu name, menu index and attribute information of each menu item control.

[0017] Optionally, the menu automatic generation module is further used to perform data binding on each menu item control to be rendered and the menu name, the menu index and the corresponding attribute information in the menu_items linked list array;

[0018] The menu automatic generation module is also used to call the GUI graphics library API interface to perform menu item graphics rendering for each menu item control to be rendered through an interface menu item mapping mechanism after data binding is completed.

[0019] Optionally, the multilingual translation module is used to determine translation attribute information according to the widgets.json file and the menus.json file;

[0020] The multilingual translation module is further used to determine multilingual translation information according to the translation attribute information.

[0021] Optionally, the message event processing mechanism is used to define callback function types for different types of message events, and respectively determine callback function logic corresponding to each callback function type;

[0022] The message event processing mechanism is also used to perform control event response encapsulation based on each element control and each menu item control through the callback function logic.

[0023] The cross-platform middleware for generating a vehicle-mounted graphical interface of the present invention comprises an interface automatic generation module, a menu automatic generation module, a message event processing mechanism, a multi-language translation module, and a GUI graphics library API interface. First, the interface automatic generation module performs data binding on each element control with the corresponding name and attribute information according to the widgets.json file of the vehicle-mounted instrument interface. Then, the menu automatic generation module performs data binding on each menu item control with the menu name, menu index and corresponding attribute information according to the menus.json file of the vehicle-mounted instrument interface. After that, the multi-language translation module determines the multi-language translation information according to the widgets.json file and the menus.json file. The message event processing mechanism performs control event response encapsulation on each element control and each menu item control. Finally, the GUI graphics library API interface performs graphic rendering of the vehicle-mounted instrument interface on each element control and each menu item control based on the multi-language translation information and the control event response encapsulation result. Compared with the prior art, which faces different requirements for interface functions and languages ​​for different car models and different markets, the development of vehicle-mounted graphical interfaces requires manual writing of a large amount of code and configuration, which is time-consuming and laborious. The present invention, through the independence of the interface automatic generation module, the menu automatic generation module, the message event processing mechanism, the multi-language translation module, and the GUI graphics library API interface, can directly generate a complete graphical interface, including menus and related functions, from a JSON file with complete graphical interface information, thereby simplifying the development process, improving development efficiency, and further improving the flexibility and scalability of the system, bringing great convenience and benefits to the development and maintenance of vehicle-mounted instruments. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 A structural block diagram of a first embodiment of a cross-platform middleware for generating an in-vehicle graphical interface according to the present invention;

[0025] Figure 2 A schematic diagram of the architecture of the first embodiment of the cross-platform middleware for generating the vehicle-mounted graphical interface of the present invention;

[0026] Figure 3A schematic diagram of describing a widgets.json file of a first embodiment of a cross-platform middleware for generating an in-vehicle graphical interface according to the present invention;

[0027] Figure 4 A schematic diagram of the widget_items data structure of the first embodiment of the cross-platform middleware generated for the vehicle-mounted graphical interface of the present invention;

[0028] Figure 5 A schematic diagram of describing a menus.json file of a first embodiment of a cross-platform middleware for generating an in-vehicle graphical interface according to the present invention;

[0029] Figure 6 A schematic diagram of a container abstract model for a first embodiment of a cross-platform middleware generated for an in-vehicle graphical interface of the present invention;

[0030] Figure 7 A menu interface diagram of the first embodiment of the cross-platform middleware generated by the vehicle-mounted graphical interface of the present invention;

[0031] Figure 8 A menu naming diagram for the first embodiment of the cross-platform middleware generated by the vehicle-mounted graphical interface of the present invention;

[0032] Fig. 9 A message event processing mechanism architecture diagram of the first embodiment of the cross-platform middleware generated for the vehicle-mounted graphical interface of the present invention;

[0033] Fig.10 A schematic diagram of the GUI graphics library encapsulation principle of the first embodiment of the cross-platform middleware for generating the vehicle-mounted graphical interface of the present invention;

[0034] Fig.11 A schematic diagram of the intelligent cockpit instrument interface of the first embodiment of the cross-platform middleware for generating a vehicle-mounted graphical interface according to the present invention;

[0035] Fig.12 Schematic diagram of the smart cockpit menu interface of the first embodiment of the cross-platform middleware generated by the vehicle-mounted graphical interface of the present invention.

[0036] The realization of the purpose, functional features and advantages of the present invention will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0037] It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not used to limit the present invention.

[0038] The embodiment of the present invention provides a cross-platform middleware for generating a vehicle-mounted graphical interface. Figure 1 , Figure 1 A structural block diagram of the first embodiment of the cross-platform middleware for generating a vehicle-mounted graphical interface according to the present invention.

[0039] In this embodiment, the cross-platform middleware for generating the vehicle-mounted graphical interface includes an interface automatic generation module 1001 , a menu automatic generation module 1002 , a message event processing mechanism 1003 , a multi-language translation module 1004 , and a GUI graphics library API interface 1005 .

[0040] In the specific implementation, refer to Figure 2 , Figure 2 The schematic diagram of the architecture of the first embodiment of the cross-platform middleware for generating the vehicle-mounted graphical interface of the present invention shows that the interface automatic generation module, menu automatic generation module, message event processing mechanism, multi-language translation module, and GUI graphics library API interface are all independent modules. EGEF (i.e., the cross-platform middleware for generating the vehicle-mounted graphical interface) can directly generate a complete graphical interface, including menus and related functions, thereby simplifying the development process, improving development efficiency, and improving the flexibility and scalability of the system, bringing great convenience and benefits to the development and maintenance of the smart cockpit.

[0041] In the present embodiment, the specific attribute information of all controls is built and managed by the automatic interface generation module. When the page is initialized, the interface element mapping mechanism displays all initialized controls on the graphical interface. Except for the construction of the interface, EGEF has also encapsulated and integrated the GUI graphics library. By encapsulating the GUI graphics library, the framework provides a unified interface and abstraction layer, so that developers can switch seamlessly between different graphics libraries, while also improving the portability and maintainability of the code.

[0042] EGEF also designs a menu generation module. The menu is abstracted into a common structure, making the management and switching of the menu more flexible and convenient. By parsing the menu items defined in the menu description file and combining the interface menu item mapping mechanism, EGEF can save all menu items and render the sub-items of the current menu to the graphical interface when the key message is notified to switch the menu, realizing the automatic generation and management of the menu to meet the common menu operation requirements in the cockpit system.

[0043] EGEF also integrates multi-language functions. By parsing multi-language translation resource files, all texts can be switched to different languages. This allows the application to provide a more friendly and user-friendly interface in different language environments, enhancing the application's usability and user experience.

[0044] The message event processing mechanism is another important module in EGEF. It implements a message event distribution mechanism that distributes all message events to the current page and all its child windows. All controls can choose to filter or process these message events, thereby achieving more flexible and customizable user interface interaction. Through the message event processing mechanism, developers can easily define various user interaction event templates, such as button clicks, text input, etc., and define the corresponding processing logic, so that the application can better respond to user operations and improve the interactivity and customizability of the system.

[0045] The automatic interface generation module 1001 is used to perform data binding on each element control with the corresponding name and attribute information according to the widgets.json file of the vehicle instrument interface.

[0046] Furthermore, the interface automatic generation module reads the widgets.json file of the vehicle instrument interface, obtains multiple element control information, and saves the multiple element control information into the widget_items linked list array; based on the widget_items linked list array, the element control information is parsed in turn to obtain the name of each element control and the attribute information of each element control, and there is a one-to-one correspondence between the name of the element control and the attribute information of the element control. The element controls to be rendered are respectively data-bound with the corresponding names and attribute information in the widget_items linked list array. After the data binding is completed, the element controls to be rendered are called through the interface element mapping mechanism to the GUI graphics library API interface for element graphics rendering.

[0047] In the specific implementation, for independent controls, the software provides an automated tool that can automatically identify the size and positioning coordinates of each control on the graphical interface in the UI design renderings based on the control cutouts provided by the artist, and automatically export the positioning coordinates of each control to the widgets.json file for storage. Controls placed in advance in the interface design tool do not need to fill in coordinates and other information, but require the graphical interface to automatically generate and create controls later. Use the above automated tool to export the coordinates of each control, and then add view and page attributes. After completion, it will be automatically mapped to the interface. Reference Figure 3 , Figure 3 A schematic diagram of describing the widgets.json file of the first embodiment of the cross-platform middleware generated for the vehicle-mounted graphical interface of the present invention. Widgets.json is used to describe independent controls.

[0048] The interface automatic generation module reads in the widgets.json file and parses it, traverses and saves all controls and attributes in the widget_items linked list array, analyzes the content in the widget_items array, parses the control names and attributes, and then sets the attributes of all controls. While setting, it will trigger the callback function, bind the controls on the interface to the data in widget_items, and thus map the entire control and attributes to the interface.

[0049] In this embodiment, by loading the interface code, each control and its attributes are mapped through the EGEF_widgets data structure, where the hierarchical structure of the control is identified by the parent control id, and each control is saved in the widget_items linked list array in the order of loading. Figure 4 As shown in the figure, each widget in the widget_items linked list array represents a control in the array. Each control contains member variables such as a pointer to the control attribute NODE list, the control name, the control type, and a pointer to the actual control in the interface. Figure 4 As shown, Figure 4 This is a schematic diagram of the widget_items data structure of the first embodiment of the cross-platform middleware generated for the vehicle-mounted graphical interface of the present invention. The framework traverses the widget_items linked list array, parses and analyzes all the properties of each control in the widget_items linked list array, and finds the index subscript number of the parent control in the widget_items linked list array according to the parent control name and fills it into the parent control id attribute of the current control, so as to build the hierarchical structure of the page. When the page is initialized, the framework traverses the widget_items linked list array again, automatically creates the real control on the interface according to each control and its properties, and points the pointer of the current data structure to the actual control in the interface. If it is detected that the current control has a parent control, the parent control will be created first; if the parent control has been created, the parent control id will be directly recorded so that the child control can be automatically destroyed when the parent control is destroyed later.

[0050] It should be understood that EGEF can manage the registration, modification and destruction of all controls, and trigger corresponding callback functions for user processing. These callback functions usually include the processing logic of user interaction events such as control click events and text input events.

[0051] The interface automatic generation module parses the control information and properties defined in the josn file, saves the control data structure and initializes the page through the interface element mapping mechanism, and realizes the automatic generation of the graphical interface. In addition, through the dynamic parsing and automatic rendering mechanism of this module, the interface code file can be replaced to achieve the purpose of dynamic skin replacement.

[0052] The menu automatic generation module 1002 is used to perform data binding on each menu item control with the menu name, the menu index and the corresponding attribute information according to the menu.json file of the vehicle instrument interface.

[0053] Furthermore, the menu automatic generation module reads the menu.json file of the vehicle-mounted instrument interface, obtains multiple menu item control information, and saves the multiple menu item control information into the menu_items linked list array; based on the menu_items linked list array, the menu item control information is parsed in turn to obtain the menu name, menu index and attribute information of each menu item control; each menu item control to be rendered is data-bound with the menu name, menu index and corresponding attribute information in the menu_items linked list array respectively, and after the data binding is completed, the menu item controls to be rendered are called through the interface menu item mapping mechanism The GUI graphics library API interface performs menu item graphics rendering.

[0054] In this embodiment, menus.json is used to describe menu items. For conventional menu items, in order to facilitate mapping, the control names in each menu item are the same, corresponding one-to-one to the controls on the interface. If there are non-standard controls here, you can set the visible property of the standard control to false, and then add other controls. info10 is a menu item, where the id "1-0, 2-0" and so on are first-level menus, and the id "1-1, 1-2" and so on are second-level menus. We need to fill in the specific parameter values ​​of the three controls fronticon, textlabel, and backicon. Through demand analysis, it is not difficult to find that there are differences between the first and second levels. The first-level menu has the first control image, the second control is label, and there is no third control. The second-level menu does not have the first control, the second control is pinned to the top left, and the third control is image, so we need to process the second control. The second-level menu needs to add the attribute value of xoffset, and then the third control needs to be displayed. We only need to modify the visible attribute to TRUE, refer to Figure 5 , Figure 5 A schematic diagram of describing the menus.json file of the first embodiment of the cross-platform middleware generated for the vehicle-mounted graphical interface of the present invention.

[0055] The menu automatic generation module reads the menus.json file and parses it, traverses and saves all controls and properties in the menu_items linked list array, analyzes the contents in the menu_items array, parses the menu name and menu index, and passes in first_level_id and second_level_id according to the menu id string, which can also speed up the search. Then, the properties of all controls in the menu item are set, and the callback function will be triggered at the same time, binding the controls on the interface to the data in menu_items, thereby mapping the entire menu hierarchy structure to the interface.

[0056] The amount of control data contained in each menu means that each row of menu items contains at most 3-4 controls, as follows Figure 7 As shown, Figure 7 This is a menu interface diagram of the first embodiment of the cross-platform middleware generated for the vehicle-mounted graphical interface of the present invention, wherein the circles represent image, label and image, which correspond to the first control, the second control and the third control in the menus.json file respectively, and the mapping relationship is reflected here.

[0057] It should also be noted that the reference Figure 6 , Figure 6 This is a schematic diagram of the container abstract model of the first embodiment of the cross-platform middleware generated for the vehicle-mounted graphical interface of the present invention. The menu description file is an abstract description of the menu structure, layout and functions, and is written in a specific format. Each menu item contains information such as id, front_image, label and end_image, where the format of id is "1-1-1", and the image and label controls contain properties such as control name, type, text content and visibility, which are converted into data structures for storage. The menu automatic generation module needs to design a corresponding parser that can parse the menu description file and save it to Figure 6 The menu_items linked list array in the menu is used for subsequent menu management and operation.

[0058] Menu item mapping mechanism: This mechanism is to associate the menu items defined in the menu description file with the menu controls on the actual interface. By parsing the menu data in the menu_items linked list array, the menu structure information in each row of menu items is automatically mapped to the menu controls on the interface, thus forming a binding relationship between the menu and the "container".

[0059] Automatic generation of menus: During the initialization phase, the framework will automatically create menu controls based on the content in the menu description file and add them to the interface. The menu management module also has a key message processing module, which is bound through the key data structure, so that the framework can dynamically query all sub-item data of menu items according to the current menu status, and dynamically render the menu controls on the interface, thereby realizing the switching and updating of menu items.

[0060] It should be understood that the menu automatic generation module can realize flexible configuration and management of menus. When it is necessary to switch menus or update menu items, the framework will re-render the menu controls on the interface according to the queried menu sub-item data, thereby realizing dynamic management and update of menus. Through the above design, the application can more conveniently customize and expand menu functions, while improving the maintainability and scalability of the system.

[0061] It should also be noted that in order to facilitate binding, the control names in each menu item should be regular, as follows Figure 8 As shown, Figure 8 The menu naming diagram of the first embodiment of the cross-platform middleware generated for the vehicle-mounted graphical interface of the present invention sets the names to image00, image11, etc., to facilitate traversal indexing in a for loop. If the menu item does not need to bind controls, there is no special requirement for naming.

[0062] The multi-language translation module 1003 is used to determine multi-language translation information according to the widgets.json file and the menus.json file.

[0063] Furthermore, the multilingual translation module determines translation attribute information according to the widgets.json file and the menus.json file, and determines multilingual translation information according to the translation attribute information.

[0064] It should be understood that the multi-language translation resource file analysis: This embodiment designs the translation format in the translation resource file, such as "info*text*basic information". Wherein "info" is the control name, "text" is the control attribute (i.e., translation attribute information), and "basic information" is the specific content of the translation (i.e., multi-language translation information). In this way, the multi-language translation resource file is stored in the file system, and EGEF can read the multi-language translation resource file at any time and parse the text content therein when translation is required.

[0065] It should also be noted that when the user selects the language of the interface, EGEF finds the corresponding translation resource file according to the user's selection and parses it, obtains all control names to find the corresponding controls in the two linked list arrays of widget_items and menu_items, and dynamically sets the specific content of the translation through a unified control property modification interface, thereby realizing multi-language translation.

[0066] The realization of multi-language function is not only a basic requirement of the intelligent cockpit graphics system, but also an important way to enhance the international competitiveness of the system and user experience. Through reasonable design and implementation, the system can better meet the language needs of different user groups and provide users with a more convenient and comfortable experience.

[0067] The message event processing mechanism 1004 is used to encapsulate control event responses for each element control and each menu item control.

[0068] Furthermore, the message event processing mechanism defines callback function types for different types of message events, and determines the callback function logic corresponding to each callback function type; and encapsulates control event responses based on the callback function logic based on each element control and each menu item control.

[0069] The message event processing mechanism is mainly responsible for the reception, transmission and distribution of message events. During the system initialization phase, EGEF will create a high-priority message service thread, allocate memory space for the message event distributor, and initialize its structure member variables to empty. Subsequently, the message event callback functions of the registered pages and views are registered in the message event distributor so that corresponding processing can be performed when messages are received.

[0070] When registering a page event, the framework allocates memory for the page and registers the page's message event callback function to the corresponding member variable of the message event dispatcher. When registering a view event, the framework allocates memory for each view node, stores the view's message event callback function in the corresponding view node, and inserts the view node into the view linked list of the event dispatcher according to the head insertion method.

[0071] The framework uses message drive as the processing mechanism of the message module. In the distribution stage of message events, the framework will obtain various events generated by the underlying system in real time, such as keyboard clicks, sensor anomalies, and touch screen operations, and convert them into specific messages and send them to the message queue. The message event distributor will pass the message event to the registered page and view, and distribute the received message event to each control. The event processing function of each control will decide whether to intercept and process the message. The message will not be destroyed until the return termination flag is received. The message event processing mechanism architecture is as follows: Fig. 9 As shown, Fig. 9This is a message event processing mechanism architecture diagram of the first embodiment of the cross-platform middleware generated for the vehicle-mounted graphical interface of the present invention.

[0072] After the software completes the drawing and property setting of all controls, it encapsulates the event response of each control, including control activation, click, animation and other special events. Users only need to call the encapsulation method of the event to control the event response of the corresponding control.

[0073] In the smart cockpit graphics system, the callback function of the message event is responsible for performing corresponding operations based on the type and content of the received message. First, the framework needs to define the callback function types for different types of message events. These callback function types usually include key events, system messages, external device messages, etc. Each message type will have a corresponding callback function type to handle the operation of that type of message.

[0074] When the system is initialized or a specific event occurs, the pre-defined callback function is bound and registered with the corresponding message type. After the message event reaches the graphics middleware layer, the framework can call the corresponding callback function to process the message according to the message type. Subsequently, for each message type, the user needs to write the corresponding callback function logic. This logic usually includes parsing and processing the message content, and performing corresponding operations. For example, for a key event, the callback function may detect the type of key pressed and perform corresponding interface operations or business logic.

[0075] In the callback function of the message event, it is necessary to return the processed flag after processing the message event to prevent the message event from being processed twice. This message event processing mechanism can ensure that the system responds to various message events in a timely and accurate manner, improving the reliability and stability of the system.

[0076] The GUI graphics library API interface 1005 is used to perform graphics rendering of the vehicle instrument interface for each element control and each menu item control based on the multi-language translation information and the control event response encapsulation result.

[0077] It should also be noted that in traditional embedded graphics system development, GUI development is often based on a specific GUI graphics library. After selecting a specific GUI graphics library, developers usually need to interact directly with the graphics library and tightly couple the business logic with the GUI controls. This traditional development method has some problems. First, since different GUI graphics libraries have different interfaces and implementation methods, once a graphics library is selected, it is difficult to replace or upgrade it later. Second, due to the high degree of coupling between business logic and interface controls, direct interaction with the GUI graphics library may reduce the maintainability and portability of the code.

[0078] In order to solve these problems, it is necessary to design a universal interface to deal with different GUI graphics libraries, decouple business logic from the graphical interface, and improve the portability and maintainability of the code. The GUI graphics library encapsulation principle is as follows: Fig.10 As shown, Fig.10 A schematic diagram of the GUI graphics library encapsulation principle of the first embodiment of the cross-platform middleware for generating the vehicle-mounted graphical interface of the present invention.

[0079] When encapsulating a GUI graphics library, the following aspects need to be considered:

[0080] (1) General interface design: When encapsulating a GUI graphics library, the first task is to design a set of general interfaces that cover common interface element operations, such as creating controls, setting properties, and destroying controls. These interfaces should be able to achieve seamless switching between different GUI graphics libraries without modifying the business logic, so that upper-level applications can easily adapt to different graphics libraries.

[0081] (2) Abstract encapsulation layer: This layer can hide specific implementation details and provide a simple and unified interface for upper-layer applications. Through this abstract encapsulation, the coupling between the application and the GUI graphics library can be reduced, thereby improving the flexibility and maintainability of the code.

[0082] (3) Platform compatibility: Considering the differences between different operating system platforms, the encapsulation of the GUI graphics library needs to have good platform compatibility. This means that the corresponding underlying libraries need to be called for different operating systems to ensure that the application can run normally on various mainstream operating systems and provide a consistent user experience.

[0083] (4) GUI graphics library API encapsulation: GUI graphics library API encapsulation is to encapsulate the functions of all controls, making them compatible with different programming languages ​​(such as C, C++, etc.) and providing a unified calling interface. Such encapsulation enables developers to use the GUI graphics library more conveniently and realize cross-platform graphical interface application development.

[0084] It should be understood that the encapsulation of the GUI graphics library plays a key role in the implementation of the smart cockpit graphics middleware. After encapsulating the GUI graphics library, developers can operate different GUI graphics libraries through a unified interface without having to worry about the underlying implementation details. This abstract design makes the system easier to maintain and expand, and can run on different hardware platforms, improving the portability and applicability of the system.

[0085] The encapsulation of the GUI graphics library further improves the performance and efficiency of the system. By encapsulating the GUI graphics library, the calling method of the GUI graphics library can be optimized, and unnecessary resource consumption and operating overhead can be reduced. In addition, after encapsulating the GUI graphics library, the graphics middleware can also provide additional functions and extended interfaces to meet the needs of different application scenarios.

[0086] In this embodiment, during the implementation of the graphical interface generation framework, the interface code is first generated by parsing the josn code, and then the automatic generation of the smart cockpit graphical interface is realized through the interface element mapping mechanism. The josn file corresponds to a set of skin styles. Through this mapping mechanism, the smart cockpit can obtain different josn file code files in the skin market at runtime, dynamically parse and automatically generate different graphical interfaces to meet changing needs, and ensure the consistency and accuracy of the interface. The corresponding smart cockpit instrument interface is automatically generated according to the josn code file, refer to Fig.11 , Fig.11 Schematic diagram of the smart cockpit instrument interface of the first embodiment of the cross-platform middleware generated by the vehicle-mounted graphical interface of the present invention.

[0087] It should also be noted that the reference Fig.12 , Fig.12 This is a schematic diagram of the smart cockpit menu interface of the first embodiment of the cross-platform middleware generated by the vehicle-mounted graphical interface of the present invention. The menu automatic generation module can automatically create a menu interface according to the functional requirements of the smart cockpit and the user interaction design. The menu interface is an important part of the smart cockpit graphical interface, which directly affects the user's access to system functions and operating experience. By adding the menu module, developers can easily generate a menu interface that meets the requirements, avoiding the tedious process of manually writing menu codes.

[0088] The graphical interface generation framework can generate a graphical interface that meets the requirements of the smart cockpit, with a clear interface layout and complete functions. These renderings fully demonstrate the actual application effect of the graphical interface generation framework, providing reliable support and reference for the development of smart cockpit technology.

[0089] In this embodiment, first, the interface automatic generation module performs data binding on each element control with the corresponding name and attribute information according to the widgets.json file of the vehicle instrument interface, and then the menu automatic generation module performs data binding on each menu item control with the menu name, menu index and corresponding attribute information according to the menu.json file of the vehicle instrument interface. Thereafter, the multilingual translation module determines the multilingual translation information according to the widgets.json file and the menu.json file, and the message event processing mechanism performs control event response encapsulation on each element control and each menu item control. Finally, the GUI graphics library API interface performs graphics rendering of the vehicle instrument interface on each element control and each menu item control based on the multilingual translation information and the control event response encapsulation results. Compared with the existing technology, which faces different requirements for interface functions and languages ​​for different car models and different markets, the development of vehicle-mounted graphical interfaces requires manual writing of a large amount of code and configuration, which is time-consuming and laborious. However, this embodiment provides a stable and efficient basic support for the intelligent cockpit graphics system through the independence of the interface automatic generation module, menu automatic generation module, message event processing mechanism, multi-language translation module, and GUI graphics library API interface, and the design and implementation of the modules, providing an important guarantee for improving the system's functions and performance.

[0090] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or system including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or system. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or system including the element.

[0091] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

[0092] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as a read-only memory / random access memory, a magnetic disk, or an optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present invention.

[0093] The above are only preferred embodiments of the present invention, and are not intended to limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made using the contents of the present invention specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A cross-platform middleware for generating an in-vehicle graphical interface, characterized in that: The cross-platform middleware for vehicle-mounted graphical interface generation includes an interface automatic generation module, a menu automatic generation module, a message event processing mechanism, a multi-language translation module, and a GUI graphics library API interface; The automatic interface generation module is used to perform data binding of each element control with the corresponding name and attribute information according to the widgets.json file of the vehicle instrument interface; The menu automatic generation module is used to perform data binding on each menu item control with the menu name, the menu index and the corresponding attribute information according to the menu.json file of the vehicle instrument interface; The multilingual translation module is used to determine multilingual translation information according to the widgets.json file and the menus.json file; The message event processing mechanism is used to encapsulate control event responses for each element control and each menu item control; The GUI graphics library API interface is used to perform graphics rendering of the vehicle instrument interface for each element control and each menu item control based on the multi-language translation information and the control event response encapsulation result.

2. The cross-platform middleware according to claim 1, characterized in that: The automatic interface generation module is used to read the widgets.json file of the vehicle instrument interface, obtain multiple element control information, and save the multiple element control information into the widget_items linked list array; The automatic interface generation module is also used to parse the information of each element control in sequence based on the widget_items linked list array to obtain the name of each element control and the attribute information of each element control. There is a one-to-one correspondence between the name of the element control and the attribute information of the element control.

3. The cross-platform middleware according to claim 2, characterized in that: The automatic interface generation module is also used to perform data binding on each element control to be rendered and the corresponding name and attribute information in the widget_items linked list array; The automatic interface generation module is also used to call the GUI graphics library API interface to perform element graphics rendering on each element control to be rendered through an interface element mapping mechanism after data binding is completed.

4. The cross-platform middleware according to claim 1, characterized in that: The menu automatic generation module is used to read the menu.json file of the vehicle instrument interface, obtain multiple menu item control information, and save the multiple menu item control information into the menu_items linked list array; The menu automatic generation module is also used to parse the control information of each menu item in sequence based on the menu_items linked list array to obtain the menu name, menu index and attribute information of each menu item control.

5. The cross-platform middleware according to claim 4, characterized in that: The menu automatic generation module is also used to perform data binding on each menu item control to be rendered and the menu name, the menu index and the corresponding attribute information in the menu_items linked list array; The menu automatic generation module is also used to call the GUI graphics library API interface to perform menu item graphics rendering for each menu item control to be rendered through an interface menu item mapping mechanism after data binding is completed.

6. The cross-platform middleware according to claim 1, characterized in that: The multilingual translation module is used to determine translation attribute information according to the widgets.json file and the menus.json file; The multilingual translation module is further used to determine multilingual translation information according to the translation attribute information.

7. The cross-platform middleware according to claim 1, characterized in that: The message event processing mechanism is used to define callback function types for different types of message events and respectively determine the callback function logic corresponding to each callback function type; The message event processing mechanism is also used to perform control event response encapsulation based on each element control and each menu item control through the callback function logic.

Images