System and method for implementing a dynamically stylable open graphics library

A system to implement a dynamically stylable open graphics library is disclosed. The system includes a memory configured to store machine readable instructions and data and a processing unit. The machine readable instructions and data include a view configuration file that defines view format areas of a graphical user interface where the elements of the graphical user interface are placeable, a layout configuration file that defines a layout of the elements within an area described by the view configuration file on a screen display, a style configuration file that defines a style of the elements, a graphical user interface engine configured to process the style configuration file, the layout configuration file, and the view configuration file and render the elements onto the screen display, and an interface that allows changes to be made to the configuration files by editing a language representative of the format of the configuration files.

TECHNICAL FIELD

This relates to software systems for implementing graphical user interfaces, or more particularly to a system and method for implementing a dynamically stylable open graphics library.

BACKGROUND

Graphical user interfaces (GUIs) allow users to interact with electronic devices through graphical icons and visual indicators. Actions within a GUI are commonly performed by directly manipulating graphical elements such as windows, menus, and icons on a display. In a flight deck environment, the graphical user interface conveys information to a user (e.g., a pilot) including telltale indicators such as fuel level, altitude, and mission status. A GUI builder or a GUI designer is a software development tool that facilitates the creation of GUIs by allowing a user experience designer to arrange control elements using a drag and drop editor. User interfaces are typically programmed using an event-driven architecture in which supporting code connects control elements with application logic.

SUMMARY

In one example, a system to implement a dynamically stylable open graphics library is disclosed. The system includes a memory configured to store machine readable instructions and data and a processing unit configured to access the memory and execute the machine-readable instructions. The machine readable instructions and data include a view configuration file that defines view format areas of a graphical user interface where the elements of the graphical user interface are placeable, a layout configuration file that defines a layout of the elements within an area described by the view configuration file on a screen display, a style configuration file that defines a style of the elements, a graphical user interface engine configured to process the style configuration file, the layout configuration file, and the view configuration file, and render the elements onto the screen display, and an interface, the interface allowing changes to be made to the style configuration file, the layout configuration file, and/or the view configuration file by editing a language representative of the format of the view configuration file, the layout configuration file, and the style configuration file.

In another example, a method for dynamically changing elements within a graphical user interface (GUI) during runtime is disclosed. The method includes changing a style configuration file, a layout configuration file, or a view configuration file while a GUI application is executing, actuating an actuation control during runtime, implementing a runtime reload of the style configuration file, the layout configuration file, or the view configuration file that has been changed in response to actuation of the actuation control, and determining a style of the elements to create a runtime-configured display of styled elements on a GUI screen display.

In yet another example, a non-transitory computer readable medium to implement a dynamically stylable open graphics library is disclosed. The system includes a view configuration file that defines view format areas of a graphical user interface where the elements of the graphical user interface are placeable, a layout configuration file that defines a layout of the elements within an area described by the view configuration file on a screen display, a style configuration file that defines a style of the elements, and a graphical user interface engine configured to process the style configuration file, the layout configuration file, and the view configuration file and render the elements onto the screen display, and an actuation control, wherein actuating the actuation control during runtime implements a runtime load of the style configuration file, the layout configuration file, and/or the view configuration file that have been changed to create a runtime-configured display on the screen display.

DETAILED DESCRIPTION

Disclosed herein is a system and method to implement a dynamically stylable open graphics library. The system allows a user to change the user experience (user interface) in real-time, in the run-time environment, without the need to modify, recertify, or recompile backend core software. To implement a runtime display change, the user changes one or more configuration files. The user then actuates an actuation control to reload the changed configuration files during runtime, the elements on the graphical user interface change styles in accordance with the change to the configuration files.

In computing, dynamic loading (or runtime loading) is the process by which a computer program, during execution time (runtime), loads a library or other binary into memory, retrieves the addresses of functions and variables contained in the library, executes those functions or accesses those variables, and unloads the library from memory. Thus, a runtime load implemented by the system disclosed herein will update a graphical user interface (GUI) display while an application is executing based on a current configuration of a number of configuration files that define a format for the display. Typically, the system is loaded by actuating (e.g., by a user) an actuation control. As used herein, a “runtime reload” updates the display while an application is executing based on a current configuration of a number of configuration files that define a format for the display, after the configuration files have been loaded at least once. Reflection, implemented using reflection files, is one way to implement dynamic loading.

The user interface implemented by the system disclosed herein can be changed based on a number of language preferences, functionality, types of control elements, color of backgrounds and fonts, icons, etc. The system disclosed herein contrasts with systems that require a change to the source code, a recompilation, and a recertification whenever there is a change to the user interface. Additionally, the system enables functional code and interface code to be developed independently. That is, changing the functional code does not necessarily impact the interface code and vice versa.

The system includes a graphical user interface engine that pulls in and processes multiple types of configuration files that define the format of the display. The configuration files include view configuration files, layout configuration files, and style configuration files. The system combines complex style inheritance allowing aspects of the style of a control (e.g., from color, rounded corners, etc.) to be inherited with dynamic layout of control elements. The system provides for access to dynamic data values (e.g., telltale indicators such as platform position or fuel flow rate) that can be inserted into a layout file to drive controls dynamically without having to change or recertify underlying control code. A user or user experience team can dynamically use the engine to build displays without shutting the system down.

The system includes a functional code engine that is linked to the graphical user interface engine in order to bind a specific functionality to the elements. In other systems, a developer would create both functional and control element (e.g., widget) code concurrently, such that the control element code is tightly bound to the functional code and such that new controls require new code. In contrast, the present system allows a developer to develop functional code without having any foreknowledge of the control element (e.g., widget) code. Rather, the functional code engine is linked to the graphical user interface engine that implements the code for the control elements to bind the functional aspects of the control elements to the graphical representation of the control elements. Thus, the developers are freed to focus on functional development while user experience teams and users focus on configuring the graphical user interface experience.

The system is applicable in any setting that utilizes a graphical user interface. These application settings include, for example, defense, commercial aerospace, petrochemical, railroad, automotive, and medical equipment. As some examples, the system is deployable to flight deck environments, mission payload operator stations and ground stations.

FIG. 1is an architecture diagram of a system100that implements a dynamically stylable open graphics library. As shown inFIG. 1, the system100includes a set116of elements114, the set116of elements114including elements1through N, where N is an integer greater than or equal to 1. The elements114are rendered to the graphical user interface (GUI) screen display118of the system100by the graphical user interface engine110. The elements114include control elements configured to display data or interact with underlying data in response to user input, container elements comprising one or more control elements, sub-control elements that inherit features of a parent control element, sub-container elements that inherit features of a parent container element. The GUI screen display118is arranged with various layers that when combined determine where the elements114will fit. The elements114fit into containers that fit into other containers that may contain graphics or controls. The elements114also include a code-controlled state style specified in the style configuration files106. In some examples, the code-controlled state style includes the features of focus, hover, selected, and action. In some examples, the control elements comprise buttons, radio controls, spin controls, checkboxes, list boxes, text entry items, gauges, and table forms.

The system100includes a view layout configuration101. The view layout configuration101includes elements that describe how items and elements are laid out onto the GUI screen display118. In some examples, the GUI screen display118is an LCD screen display. The view layout configuration101includes a format103that includes a view configuration file102. The format103defines the look and feel of an entire display having a number of functions that are combined to produce the entire display. The view configuration file102is a configuration file that defines view format areas of the GUI screen display118where elements are placeable within the GUI screen display118. The view layout configuration101also includes a number of components105. The components105provide functionality for the elements114of the system100. In the example shown inFIG. 1, there are K such components105, where K is an integer greater than or equal to 1. The components105include a corresponding layout configuration file104. The layout configuration files104are configuration files that define a layout of the elements114within an area described by the view configuration file102on the GUI screen display118.

The system100further includes a style cache108configured to store and provide access to a number of style configuration files106. In the example shown inFIG. 1, there are R style configuration files106, where R is an integer greater than or equal to 1. The style configuration files106define a style of the elements. The style of the elements is inherited from a base style or are directly referenced inside of one of the layout configuration files104. The style of the elements114includes a visual appearance. For example, styling includes colors, line widths, background colors, etc. Other examples of styling include font, padding, margin, rounded corners radius, gradient fills, textures, size, positioning, etc. In some examples, the view configuration file102, the layout configuration files104, and the style configuration files106are implemented in extensible markup language (e.g., in .xml format).

Also included within system100and shown inFIG. 1is a graphical user interface engine110and a functional code engine112. The graphical user interface engine110is configured to process and load the style configuration files106, the layout configuration files104, and the view configuration file102and render the elements114onto the GUI screen display118in accordance with the view configurations specified by the view configuration file102, the layout configurations specified by the layout configuration files104, and the style configurations specified by the style configuration files106. The functional code engine112is linked to the graphical user interface engine110to bind a specific component functionality to the elements114by matching a functional code for an element114to a definition of an element114as specified in the view configuration file102, the layout configuration files104, and/or the style configuration files106.

The system100also includes a command line interface (CLI)132. The CLI132is a test harness which integrates the GUI screen display118for testing purposes. The CLI132allows events, such as hardware events, to be injected into the system. The CLI132also allows cursor positions to be queried to, for example, obtain information about which elements are selected. Logging into the CLI132is implemented in some examples via a remote socket connection. The CLI132also allows developers to discover the state of the graphical user interface engine110. The CLI132actively listens for commands via a Transmission Control Protocol (TCP) server socket, and in some examples is compiled out. The CLI132receives/takes commands (similar to structured query language (SQL) commands) to inject and query information from the system100. Example calls that can be made at the CLI132include “event selection press”, “get button {widget id}”, and “query {databoundid}”. In some examples, calls are returned via JavaScript Object Notation (JSON). Commands that can be implemented within the CLI132include switching screens, pressing and releasing buttons, moving in between elements, auto focusing on an element based on an element ID, querying data bound elements, sending in hardware events, and sending in text into text entry. Implementing the CLI132obviates the need for a testing team to do screen scraping for testing and eliminates the need to have information (e.g., identity information and location information) about control elements such as widgets. The testing team can just use the same layout configuration files104and style configuration files106to call elements114by name, which saves a significant amount of testing time (e.g., days of testing time).

The system100also includes an event adapter file136that describes a mapping of physical controls to events invoked by the physical controls. A hardware event is configured into an application event via the input adapter134. Application events filter into control elements. A mouse event is an example hardware event1802. Events received at the CLI132are processed by the input adapter134.

FIG. 2is block diagram of a system200that implements a dynamically stylable open graphics library. The system200includes a memory222configured to store machine readable instructions and data. The memory222can be implemented as volatile memory (e.g., random access memory), non-volatile memory (e.g., flash memory, a solid-state drive, a hard disk drive, etc.) or a combination thereof. The system200also includes a processing unit220configured to access the memory222and execute the machine-readable instructions. The processing unit220can be implemented as one or more processor cores.

The machine-readable instructions and data stored by the memory222includes various elements214that are rendered to the graphical user interface (GUI) screen display218of the system200by the graphical user interface engine210. The elements214include control elements configured to display data or interact with underlying data in response to user input, container elements comprising one or more control elements, sub-control elements that inherit features of a parent control element, sub-container elements that inherit features of a parent container element. The data stored by the memory222also includes one or more style configuration files206, layout configuration files204, and view configuration files202that define the way information is presented on the GUI screen display218. The functional code engine212is linked to the graphical user interface engine210to bind a specific component functionality to the elements by matching a functional code for an element to a definition of an element as specified in the view configuration files202, the layout configuration files204, and/or the style configuration files206.

By changing any of the configuration files (view, layout, and/or style), a user can customize the way information is organized and presented on the GUI screen display218. Accordingly, the system200also includes a configuration interface226, the configuration interface226allowing changes to be made to the style configuration files206, the layout configuration files204, and/or the view configuration files202by editing a language representative of the format of the configuration files. In some examples, the configuration interface226is a text editor.

Included in the machine-readable instructions and data of the memory222are the various other modules of the system200. In particular, the system200includes an actuation control224. Actuating the actuation control224by the user during runtime implements a runtime reload of one or more style configuration files206, layout configuration files204, and/or view configuration files202that have been changed to create a runtime-configured display on the GUI screen display218. The system200further includes a style cache208configured to store and provide access to the style configuration files206. The style configuration files206define a style of the elements which in some examples includes a visual appearance. The system200also includes a debugging subsystem228to implement a dynamic refresh of the view configuration files202, the layout configuration files204and the style configuration files206. The debugging subsystem228allows the user to view a frame rate and grid coordinates on an output terminal such as the GUI screen display218. The system200further includes hardware configuration files230that describe a mapping of physical controls to events invoked by the physical controls, such that hardware events are configured into applications events that filter into control elements214. The system200further includes a command line interface232interface integrated with the GUI screen display218, the command line interface232being configured to receive commands which inject system events and execute system queries.

FIG. 3Adepicts an example graphical user interface (GUI) screen display300, such as GUI screen display118ofFIG. 1or GUI screen display218ofFIG. 2. Various elements of the GUI screen display300are shown. Included among the elements is the overall background334, control element337, view area336, view area background335, view area338, indicator elements334, control element339, and control element background340. The GUI screen display300appears flat, but the GUI screen display300includes a number of layers.FIG. 3Bis an exploded view of the GUI screen display300depicted inFIG. 3A.FIG. 3Bshows that the GUI screen display300includes several layers 0-3. Within layer 0 is background334. Within layer 1 is view area background335, view area338, and control element background340. Within layer 2 is view area336and control element339. Within layer 3 is control element337. Thus, the GUI screen display300is arranged with various layers that when combined provide a layered architecture while specifying where the graphical elements will be placed. Elements fit into containers that fit into other containers that contain graphics or controls. Styling is applied to each of the layers and elements in order to provide colors, widths, background colors, and other style characteristics.

FIG. 4depicts a high-level organizational view400of example elements401of a GUI implemented by a dynamically stylable open graphics library, such as elements114ofFIG. 1and/or elements214ofFIG. 2. Everything on the GUI screen display (such as the GUI screen display118or the GUI screen display218) is a type of element401. As shown by the organizational view400inFIG. 4, elements401are either control elements402(e.g., widgets) or container elements403. Container elements403define a layout405of the elements401. The control elements402(e.g., BaseWidget elements) allow displaying or interacting with data. Each of the elements401is styled separately since style404is separate from a control or layout. As shown inFIG. 4, among the example control elements402is a base menu406, check button407, check list box408, circle409, combo box410, context menu411, gauge412, list box413, list control414, notification widget415, polygon416, polyline417, push button418, radio button419, scroll bar420, slider421, tab box422, text entry423, text label424, and text area425. Among the example container elements403is a box panel426, canvas427, compass panel428, grid panel429, overlay panel430, scroll panel431, and tab panel432.

FIG. 5illustrates various examples of container elements of a GUI implemented by a dynamically stylable open graphics library. The container elements are, for example, a subset of the elements114ofFIG. 1and/or the elements214ofFIG. 2. The horizontal box layout container502includes elements504(data or control elements), a strut506to provide spacing, and foam508to provide expandable padding. In some examples, box layout containers are vertical. The grid layout container510includes 20 elements (E00to E43) arranged in a grid consisting of 5 rows and 4 columns. Grid layout containers can be generalized as containing m rows and n columns such that there are m×n elements. Thus, the grid layout container510is laid out from left to right and then from top to bottom in a predefined column/row width. The canvas layout container512stacks elements one on top of the other, such as on a map. The canvas layout container512includes element layers 0 to n, where n is an integer greater than or equal to 1. The scroll layout container522has a fixed size, but when needed provides the ability to grow via a scrollable pane. The scroll layout container522includes a viewport element524that contains information, a horizontal scroll bar526, a vertical scroll bar528, and a corner element530. The book layout container532provides the ability to show one panel at a time, similar to a flipbook. Accordingly, the book layout container532includes hidden elements1to n (where n is an integer greater than or equal to 1), and a visible element x. In some examples, book layout containers include control with a series of buttons or tabs.

FIG. 6illustrates various examples of control elements (e.g., widgets) of a GUI implemented by a dynamically stylable open graphics library. The control elements are, for example, a subset of the elements114ofFIG. 1and/or the elements214ofFIG. 2.FIG. 6depicts control elements that would typically be part of a GUI within a flight deck environment, but in other examples, other control elements could be employed. Shown inFIG. 6are button control elements602, a list604of radio control elements, a spin control606, a checkbox608, a list box610, another list box612, a text entry control614, a gauge element616(showing the fuel level for Tank1), another gauge element618(showing the fuel level for Tank2), and a table form620.

During the software development process, application development typically implements large application level libraries to create control elements (e.g., widgets) and container elements. Some examples include current versions of 1) Qt (a cross-platform application framework and widget toolkit for creating classic and embedded graphical user interfaces and applications); 2) wxWidgets (a widget toolkit and tools library for creating GUIs for cross-platform applications); 3) Microsoft Foundation Class Library (MFC), a C++ object-oriented library for developing desktop applications for Windows; 4) Java Swing (a GUI widget toolkit for Java); and 5) Gtk (a cross-platform widget toolkit for creating graphical user interfaces). However, use of such application level libraries requires the developer to reconstruct a user experience (UX) designer's vision, which may be imperfect because of lack of attention to details, or the lack of an ability to make user experience enhancements due to feasibility in the framework. Thus, the UX team and the development (DEV) team wait on each other unnecessarily. The systems and methods disclosed herein solve these problems by allowing the developer team to concentrate on functional implementation without regard to layout, style, and design, while allowing the user experience team to concentrate on details such as layout, style, and design permitting the user experience and development teams to work concurrently yet independently. Thus, members of the UX team use the same engine (e.g., the graphical user interface engine110ofFIG. 1) to generate user interface mockups (for example, to generate the list of control elements requiring functionality, the mockup functioning as a draft GUI). The UX team then hands the generated mockup to the development team to integrate functionality while the UX team independently finalizes the formatting and visual aspects of the GUI.

FIG. 7thus illustrates a software/embedded application process for implementing a dynamically stylable open graphics library enabled by the systems and methods disclosed herein. At702, functional requirements are gathered. At704, the user experience (UX) team performs an initial mockup of a GUI screen display and other aspects of the user interface. At about the same time (e.g., the times overlap) that the user experience team generates a mockup, at706, the development team is developing the functional implementation. At708, the mockup from the user experience team is combined with the functional implementation developed by the development team to produce the final GUI OpenGL product. The software platforms listed above (including Qt, wxWidgets, MFC, Java Swing, and Gtk) should be adapted such that software/embedded application development can occur in accordance with the process illustrated byFIG. 7. Accordingly, the systems and method described herein create a dynamic layout and dynamically stylable OpenGL based engine that allows a UX team and a DEV team to work together. The system is cross-platform, and in some examples utilizes the C++ programming language. The system allows runtime configuration including updates to the graphical user interface when the system is executing. As indicated with respect toFIG. 1andFIG. 2, the system includes three types of configuration files, including style configuration files, layout configuration files, and one or more view configuration files. The style configuration files determine the visual appearance of the elements on the display depending on a state. The layout configuration files determine the layout for control elements (e.g., widgets). The layouts are conformed to a proper space within an overall view, as determined by a view configuration file. The view configuration files describe areas where a layout can be placed within an overall screen space.

FIG. 8Adepicts example views of a GUI implemented by a dynamically stylable open graphics library, such as the views within the view layout configuration101ofFIG. 1, and view area336and view area338ofFIGS. 3A-3B. Views ae relative windows where layouts and control elements (e.g., widgets) are placed. Views are similar to frames in HTML. A view provides a space for a layout to hook into. Some views are predefined while other views are customizable. Multiple layouts use views in a cyclical manner.FIG. 8Ashows a predefined view802, as well as three custom views, namely custom view 1804, custom view 2806, and custom view 3808. Views, therefore, are sub-areas on the GUI screen display (e.g., GUI screen display118and/or GUI screen display218) where layout configuration files are bounded and determine a layout. Views, taken in combination, make up a format or complete display area. The GUI screen display displays elements within a view at a given time depending on the specification provided by the view layout configuration (e.g., the view layout configuration101) determined by the view configuration file or layout configuration files.

FIG. 8Bdepicts different view areas for an example flight deck application implemented with a dynamically stylable open graphics library. For purposes of simplification of explanation,FIG. 8Bemploys the same reference numbers asFIG. 8Ato denote an instantiation of a view area in the flight deck application.FIG. 8Bdepicts four view areas. View are802is the main area view slot (e.g., the main area for the format). View area804is the menu slot allowing the user to select from a variety of different layouts. View area806is the map area view slot which provides a map of interest. View area808is the gutter area, which is a ribbon-like area for various contextual based layouts.

FIG. 9Ais an example style file900for a dynamically stylable open graphics library. The style file900controls the style and state of elements within a layout. The style file900defines a base control style for a button, beginning at902(“Button Style Start”) and ending at904(“Button Style End”). The style file900allows styling of the smallest elements (e.g., a “sub style”) within a control element (e.g., the drop arrow in a ComboBox). In some examples, styles inherit from a base style. In other examples, styles are directly referenced inside of a layout file or are inherited by a control type. For example, a button takes the base style “button”, or alternatively, takes on a style specified in a layout file.FIG. 9Bis an example style file925that produces a control button930containing the text “BRAVO”. Control button930is a control element. The style file925specifies various aspects of the control button930, including as the button's color at931, that the button has rounded corners of a particular radius at932, the font type at933, the emphasis at934, the font size of the text “BRAVO” at935, and the alignment936of the text “BRAVO” within the button.FIG. 9Cis an example style file950that produces two check buttons, check button960and check button962. Among other specifications, the style file950specifies that the check button962is disabled (disabled is an example state style), at963, and unchecked (unchecked is also an example state style), at964.FIG. 9Dis an example style file975that specifies aspects of an example spin control980. Among the aspects specified by the style file975include the overall aspects of the spin control980beginning at981, the focus portion of the spin control980beginning at982, and the arrow portion of the spin control980beginning at983. The system allows every element to be stylable.

FIG. 10depicts an example list control element1000of a GUI produced by a style file of a dynamically stylable open graphics library. The list control element1000(corresponding to a programming object, e.g., listCtrl) is composed of several sub-elements. The list control element1000includes a header element1002corresponding to a programming object, e.g., listCtrl.header. The list control element1000includes two-tab elements corresponding to programming objects, e.g., listCtrl.headerTab1 and listCtrl.headerTab2). The list control element1000includes tab element1004(“Col2 Header”) and tab element1006(“Col1 Header”). The list control element1000includes four cell elements corresponding to programming objects, e.g., listCtrl.itemCell1, listCtrl.itemCell2, listCtrl.itemCell3, and listCtrl.itemCell4, namely cell element1008, cell element1010, cell element1012, and cell element1014. The list control element1000includes four item elements corresponding to programming objects, e.g., listCtrl.item1, listCtrl.item2, listCtrl.item3, and listCtrl.item4, within each of the four cell elements, namely item element1016, item element1018, item element1020, and item element1022. The list control element1000includes a down button1024enabling downward vertical scrolling, and which corresponds to a programming object, e.g., listCtrl.scrollVert.downButton. The list control element1000includes a down arrow1026corresponding to a programming object, e.g., listCtrl.scrollVert.downButton.arrow, on the down button1024. The list control element1000includes a vertical scroll area1028corresponding to a programming object, e.g., listCtrl.scrollVert. The list control element1000includes a scroll bar handle1030corresponding to a programming object, e.g., listCtrl.scrollBar.handle. The list control element1000includes an up button1032enabling upward vertical scrolling, corresponding to a programming object, e.g., listCtrl.scrollVert.upButton. The list control element1000includes an up arrow1034corresponding to a programming object, e.g., listCtrl.scrollVert.upButton.arrow on the up button1032.

The list control element1000is stylable as are each of the named sub-elements within the list control element1000. Moreover, each of the elements and sub elements have corresponding code-controlled state style. Examples of state styles are focus, hover, selected, action, etc. Example styles include font, padding, margin, rounded corners radius, colors, gradient fills, textures, size, positioning, etc.

FIG. 11is an example layout configuration file1100and view area1120generated by the layout configuration file1100. The layout configuration file1100defines how various elements are shown within the view area1120of a GUI screen display. InFIG. 11, the layout configuration file1100specifies, at1102and1104, that two communications buttons appear at the top of the view area1120, namely communication button1122and communication button1124. Further, the layout configuration file1100specifies, at1106, that a vertically and horizontally scrollable list box1126has several “BLOS” items situated below the communication button1122and the communication button1124. The layout configuration file1100further specifies, at1108and1110, respectively, that below the list box1126, data is displayed both as a description box panel1128and as a grid box panel1130. The layout configuration files, such as the layout configuration file1100, control the layout of a view inside of a format. Control elements, such as widgets, and static content are added to containers and layout panels in order to dynamically control layouts. Elements can either inherit their style or have their style specified directly. Data can be statically filled or property files can be used to fill data fields (so that they can be reused across multiple layouts). Databinding is used to pull variable data directly from the system and have the data update dynamically. The layout configuration files, such as the layout configuration file1100, generate control elements (e.g., widgets) such that the standard containers and controls are generated and used by changing any one of the view configuration files, the layout configuration files, or the style configuration files. This allows a user experience (UX) team to take a layout configuration file create a display by just changing the layout configuration file on the fly, and then actuating a “hotkey” to actuate a runtime load (or runtime reload) of the GUI screen display to view a refreshed display (e.g., updates to the control elements). After the layout configuration file is created, the layout configuration file (e.g., an xml file) can be immediately used by the development (DEV) team to connect the user experience with the functionality that has been written on the backend by the development team.

FIG. 12illustrates an example linking1200of a view configuration file1202, a layout configuration file1204, and a style configuration file1206by a system implementing a dynamically stylable open graphics library. The commInfoSlot object1203is specified in the view configuration file1202by the statement:

The commInfoSlot object1203is used again in the layout configuration file1204to indicate a layout format. Further, layout configuration file1204specifies a layout format of the list control element by the statement:

Further, the style configuration file1206specifies the style of the list control by the statement:

The CommPlanList object1207indicates the layout of the list control element. In the example shown inFIG. 12, the list control element inherits the base b-list-box style since a specific style is not specified in the style configuration file1206. If a style tag is added to the list control in the style configuration file1206at1209the style is set to something other than the base style, namely that indicated by the style tag. The component layout describes a view target. If multiple layouts are assigned to a view then the display works out the contention.

The system described herein (e.g., the system100and/or the system200) can be implemented in a cross-platform manner using any general-purpose programming language such as C++. In some examples, the system implements abstraction layers so that no operating system specific calls are made. Also, in some examples, supporting software libraries are also cross-platform. Example supporting libraries that can be used are Geospatial Data Abstraction Library (GDAL), Geometry Engine Open Source (GEOS), Simple DirectMedia Layer (SDL), Shapelib, and Xerces. The graphics code is developed using a cross-language, cross-platform application programming interface, such that the development team is a level of abstraction away from graphics code unless a specialty item is required. In some examples, data input is based on Open Mission Standard (OMS) messages.

By using the system disclosed herein, developers can create control elements (e.g., widgets) either in code or force control elements into the display through direct code calls. Similarly, developers can create styles in code or force styles into the display through direct code calls. The system disclosed herein provides a one for one translation of elements (container elements, control elements) in layout configuration files, and a one for one translation of style objects in style configuration files.

FIG. 13an illustration1300of the separation of functional code1304and graphical code1308to implement a graphical user interface1310in accordance with the teachings disclosed herein. Functional code1304is created1302by a development team. Simultaneously but separately, graphical code1308is developed by a separate team (e.g., a user experience team) and then discovered1306by the development team to generate the graphical user interface1310. This paradigm stands in contrast to previous approaches where a development team would be needed to develop both the functional code1304and the graphical code1308to develop the graphical user interface1310. By using the system (e.g., system100and/or system200) described herein, the functional developers do not need foreknowledge of graphical code1308(style, view, or layout), because the control elements are discovered1306. The functional code1304is then linked to the graphical code1308(e.g., by linking a functional code engine (e.g., functional code engine112or functional code engine212) with a graphical user interface engine (e.g., graphical user interface engine110or graphical user interface engine210)), which allows functional development to be kept separate from user experience development.

In the system disclosed herein, functional code is bound to graphical code using a binding process. To bind the functional code to the graphical code, the system declares the universe of control elements that need to be bound to functional code. A bind command is then executed to match each control element with a named control in a layout file. Then, controls for events are registered. If the control element does not exist then a control element is created internally but not put into any container (effectively making it offscreen), such that they are no null pointers. All of the controls do not necessarily have to be declared in code. Rather, control elements that include functionality (e.g., those specified by the developer) are bound. The style files are used for styling the control elements (which in some examples is programmatically controlled).

The binding process also includes feeding data to the control elements. The system provides the ability to expose data elements from inside the system to allow a user experience team to add new descriptive fields or change the kind of data that is displayed. Data binding provides a way to expose internal data objects to user experience developers as well as linkages that allow developers to add dynamic content to layouts. Developers can expose methods or member variables through reflection to the user experience developers, and control elements can be linked together in layout configuration files.

FIG. 14illustrates example 1400 data binding syntax for a dynamically stylable open graphics library system. Data is set within control elements using a data attribute to an object exposed in code. Thus, inFIG. 14, the SARTaskList list control element is set through the sub-statement1402--data=“SARTasks”--. A “key” attribute declares the data element used as the key for the list. Thus, inFIG. 14, the SARTaskList list control element is assigned through the sub-statement1404--uuidKey=“m_id.uuid”--. Other elements in the layout file can call the list variable by name followed by the data method or item needed to be filled out. All dynamic fields are prepended by ${data:}. Thus, the SARTaskList object corresponding to a list control element is dynamic as specified by the statement1406:

FIG. 15illustrates an example reflection file1500used within a dynamically stylable open graphics library system. The reflection file1500corresponds to a SARTask element. The reflection file1500provides the ability to implement structural and behavioral changes during runtime, or for observing and modifying program execution at runtime. Accordingly, the system disclosed herein supports reflection, which automatically handles updates to data. Some programming languages provide direct support for reflection (e.g., C# and JAVA) while other programming languages (e.g., C++) do not provide direct support for reflection. In languages where reflection is not directly supported, the developer has to choose what is exposed (with optional description), and developers have to have an overloaded ostream operator (e.g., toString) for each custom method unless it exists for basic types. The developer benefits in that they can give over full control of an object over to a control element rather than having to pull data from an object and insert it into a list. Smart pointers are implemented to delete pointers that do not have corresponding objects associated with them.

FIG. 16is an example debug view1600of the dynamically stylable open graphics library system. Container layouts can be viewed while in debug mode. While in debug view1600with highlighted container layouts (in some examples, the container layouts are shown in different colors in debug view), including container layout1602, container layout1604, container layout1606, container layout1608, and container layout1610. A debugging subsystem (e.g., debugging subsystem228) is used to implement a dynamic refresh of the configuration files, including the view configuration files, the layout configuration files and the style configuration files. As a practical example, the debugging subsystem can be used to view a frame rate (e.g., by actuating a hotkey) and grid coordinates on the screen. In some examples, the dynamic refresh of all of the configuration files is tied to a hotkey, which allows a runtime switch to a debugging mode and updates all of the files so that a development team and a user experience team can instantly see any changes to the configuration files. While in debugging mode, grid coordinates follow a cursor and provide an indication of which control element the cursor is presently hovering over.

FIG. 17is an example property file1700used by the disclosed dynamically stylable open graphics library system. Other features of the system are the inclusion of message bundles and property files. Message bundles and property files are used so that layout configuration files are not overloaded with the same strings. Property files are implemented for quick text replacement.

FIG. 18is a block diagram illustrating a hardware interface subsystem1800implemented by the disclosed dynamically stylable open graphics library system. The hardware interface subsystem1800configures hardware events into application events. The hardware interface subsystem1800includes a hardware configuration file1808that describes a mapping of physical controls to events invoked by the physical controls. The hardware event1802is configured into an application event1806via the input adapter1804. The input adapter1804and hardware configuration file1808correspond to the input adapter134and event adapter file136, respectively, ofFIG. 1. The application event1806filters into control elements. A mouse event is an example hardware event1802. Adapters (such as input adapter1804) can be written for custom controllers (such as flight controls) and can be dynamically mapped to application events (such as application event1806). Other example application events include widget traversal, cursor movement, joystick control, and focus events etc. Furthermore, pipeline configuration files allow the system to dynamically reconfigure hardware events in order to quickly test various keymappings, with the developer being unaware of the mappings.

FIG. 19depicts an example command line interface (CLI) session1900. InFIG. 19, a command line interface (CLI) (such as the command line interface132shown inFIG. 1and the command line interface232shown inFIG. 2) controls the interaction with the GUI screen display1918. The JavaScript Object Notation (JSON) terminal1982shows the status of various commands and queries entered into the CLI. The session1900ofFIG. 19shows 1) focusing of an area1980on the GUI screen display1918, 2) moving to the next chained element (a button), 3) moving to another chained button, 4) selecting the button, and 5) then a query entity queries the system to determine which entity is actually currently selected, which is shown on the JSON1982.

FIG. 20is a flowchart2000of a method for dynamically changing elements within a graphical user interface (GUI) during runtime. At2002, a style configuration file (e.g., one of style configuration files106or style configuration files206), a layout configuration file (e.g., one of layout configuration files104or layout configuration files204), or a view configuration file (e.g., view configuration file102or one of view configuration files202) is changed while a GUI application is executing. As mentioned regarding system100and system200, the view configuration file defines view format areas of the graphical user interface where elements (e.g., elements114or elements214) are placeable, the layout configuration file defines a layout of the elements within an area described by the view configuration file on the graphical user interface, and the style configuration file defines the style of the elements. At2004, an actuation control (e.g., actuation control224) is actuated (e.g., by a user) during runtime. The actuation control is, for example, a hotkey, keyboard shortcut, or biometric recognition interface.

At2006, a runtime reload of the style configuration file, the layout configuration file, or the view configuration file that has been changed is implemented in response to actuation of the actuation control. At2008, a style of the elements is determined to create a runtime-configured display of styled elements on a GUI screen display (e.g., GUI screen display118, GUI screen display218, and/or GUI screen display300). Determining the style of the elements at2008includes, in some examples, inheriting the style of the elements from a base style, and applying the inherited style to the elements. Determining the style of the elements at2008also includes, in some examples, referencing the style of the elements directly inside of a layout file, and applying the referenced style to the elements. At2010, GUI engine is linked to a functional code engine to bind a specific component functionality to the elements by matching a functional code for an element to a definition of an element as specified in the view configuration file, the layout configuration file, and/or the style configuration file. The elements of the graphical user interface include control elements configured to display data or interact with underlying data in response to user input, container elements comprising one or more control elements, sub-control elements that inherit features of a parent control element, and sub-container elements that inherit features of a parent container element.

What have been described above are examples. It is not possible to describe every conceivable combination of components or methodologies. Many further combinations and permutations are possible. Accordingly, the disclosure is intended to embrace all such alterations, modifications, and variations that fall within the scope of this application, including the appended claims. The term “based on” means based at least in part on. Additionally, where the disclosure or claims recite “a,” “an,” “a first,” or “another” element, or the equivalent thereof, it should be interpreted to include one or more than one such element, neither requiring nor excluding two or more such elements.