MMI Data

6) Generic MMI Engine: This is the kernel component of Visual MMI Development for Storage Systems. It needs the Management API and OS Dependent API to accomplish the functionalities of target MMI application. Please refer to section 3.3.5 Generic MMI Engine.

7) Management API: This API (Application Program Interface) is depended on the features of storage systems, and it provides functions to manage underlying storage devices.

MMI programmers have to program these functions according to functional requirement documents, and Generic MMI Engine will invoke these functions.

8) OS Dependent API: Generic MMI Engine requires some functional APIs but they are OS dependent. For instance, it needs Input API to get the input of keyboard or mouse, and Display API to display the MMIs to the monitor screen of computers. We separate the OS dependent code to OS Dependent API, and let the implementation of Generic MMI Engine become more easily for various environments.

9) Target MMI Application: After MMI designers compose MMIs with Visual Authoring Tool, save them as SVG files, and use SVG Parser to transform SVG files to MMI data, we can generate target MMI application with MMI data, Generic MMI Engine, Management API and OS Dependent API.

To use the model of Visual MMI Development for Storage Systems, we describe its flow in the following steps:

Step 1) MMI designers use Visual Authoring Tool to compose wanted MMIs according to MMI requirement documents

Step 2) Save the results of Visula Authoring Tool as SVG Files.

Step 3) To speed up the development of MMIs, we can create Template SVG Files for MMI designers.

Step 4) For developers or customers, they can preview these SVG Files in web browsers.

Step 5) MMI programmers add additional information in SVG Files.

Step 6) Use SVG Parser to transform SVG Files to MMI Data.

Step 7) MMI programmers program related functions in Management API according to functional requirement documents.

Step 8) Generate the target MMI applications with MMI Data, Generic MMI Engine, Management API and OS dependent API.

3.2 Generic Software Framework for the MMI Generation of Storage Systems

The conventional software framework for the MMI generation of storage systems lacks of the support of a visual authoring system. We therefore incorporate a visual authoring system into the software framework for MMIs of storage systems. The incorporated Visual Authoring and MMI Engine are shown in figure 12. We call the new software framework as Generic Software Framework for the MMI Generation of Storage Systems, since it can be used to generate Man Machine Interfaces of many storage systems.

Figure 12. Generic Software Framework for the MMI Generation of Storage Systems

There are also four layers in Generic Software Framework for the MMI Generation of Storage Systems: 1) Visual Authoring Process, 2) Generic MMI Engine, 3) Driver Layer, and 4) Embedded Firmware. We introduce the new layers:

1) Visual Authoring Process: MMI designers use Visual Authoring Tool to compose each MMI according to the MMI requirement specification for particular utility. The authoring tool is visualized and very user-friendly. After save the results in SVG files and use SVG Parser to parse these files, we can get the MMI data for Generic MMI Engine at the end of Visual Authoring Process. For instance, MMI designers use Visual Authoring Tool to compose the MMIs of Booting Utility and Pre-OS Utility, and then generate the Booting MMI Data and Pre-OS MMI Data.

2) Generic MMI Engine: Programmers do not need to write any MMI programs, but they have to program the related functions for MMIs. We design the Generic MMI Engine as common code, and it invokes these MMI related functions. This engine also cooperates with the Management API of storage systems. The design of Generic MMI Engine is OS independent, and we separate the OS dependent functions to OS Dependent APIs. This design is helpful to implement utilities in various environments.

The 3) Driver Layer and 4) Embedded Firmware are the same as the ones in the conventional software framework for MMIs of storage systems.

After MMI designers finish the Visual Authoring Process and programmers write the related functions for MMIs, we can come out the particular utility for storage systems with the MMI Data, Generic MMI Engine, and Management API. This utility still needs Driver Layer to pass commands to Embedded Firmware of storage systems.

3.3 Implementation of Visual MMI Development for Storage Systems

To implement the Visual MMI Development for Storage Systems, we must consider five key components: 1) Visual Authoring Tool – Inkscape, 2) SVG Files, 3) SVG Parser, 4) MMI Data, and 5) Generic MMI Engine.

The first phase of Visual MMI Development for Storage Systems is Visual Authoring Process. We illustrate this procedure in figure 13, and describe the details of this process in the following sections.

Figure 13. Visual Authoring Process

3.3.1 Visual Authoring Tool -- Inkscape

In our implementation, we choose Inkscape [12] as Visual Authoring Tool. Inkscape is an open source vector graphics editor, with capabilities similar to Illustrator, Freehand, CorelDraw, or Xara X using the W3C [13] standard Scalable Vector Graphics (SVG) file format. Supported SVG features include shapes, paths, text, markers, clones, alpha blending, transforms, gradients, patterns, and grouping. Inkscape also supports Creative Commons meta-data, node editing, layers, complex path operations, bitmap tracing, text-on-path, flowed text, direct XML editing, and more. It imports formats such as JPEG, PNG, TIFF, and others and exports PNG as well as multiple vector-based formats.

The main goal of Inkscape is to create a powerful and convenient drawing tool fully compliant with XML, SVG, and CSS standards. Therefore, it is very suitable for the Visual Authoring Process of Visual MMI Development for Storage Systems.

In figure 14, it is a snapshot of the Inkscape usage.

Figure 14. Visual Authoring Tool -- Inkscape

MMI designers can use the Graphic Tools, Canvas, and Layers Manager of Inkscape to implement MMIs for storage systems. To simplify and formalize the implementation of MMIs for storage systems, we use Graphic Tools to create rectangles and texts only, and put them in the Canvas area. To compose more complex vector graphics, MMI designers can use the Layer Manager to overlap many layers of graphics.

On the other hand, MMI programmers can use the XML Editor of Inkscape to modify SVG files conveniently. They can modify the name, attributes of SVG elements, and define the relationship between lots of SVG elements, or add the related functions in the functional or other programs into SVG elements.

Figure 15 illustrates one SVG file in plan text and the XML Editor of Inkscape. We recommend MMI programmers to use the XML Editor of Inkscape to add information in SVG files.

Figure 15. Edit SVG File in the XML Editor of Inkscape

To implement man machine interfaces by Visual Authoring Process, MMI designers or programmers are free to learn the SVG language. MMI designers use Inkscape to compose wanted MMI graphics and save them to the files in SVG format. When programmers want to modify the SVG files, they do not need to handcraft the SVG file in plain text. On the contrary, programmers can use the XML editor of Inkscape to edit SVG file easily and user-friendly.

3.3.2 SVG Files

SVG (Scalable Vector Graphics) [14] is a language for describing two-dimensional graphics and graphical applications in XML (Extensible Markup Language) [15]. XML is a simple, very flexible text format derived from SGML (ISO 8879). Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere.

SVG is used in many business areas including Web graphics, animation, user interfaces, graphics interchange, print and hardcopy output, mobile applications and high-quality design. It has two parts: an XML-based file format and a programming API for graphical applications. Key features include shapes, text and embedded raster graphics, with many different painting styles. It supports scripting through languages such as ECMAScript and has comprehensive support for animation.

SVG is a royalty-free vendor-neutral open standard developed under the W3C Process.

It has strong industry support; Authors of the SVG specification include Adobe, Agfa, Apple, Canon, Corel, Ericsson, HP, IBM, Kodak, Macromedia, Microsoft, Nokia, Sharp and Sun Microsystems. SVG viewers are deployed to over 100 million desktops, and there is a broad range of support in many authoring tools.

SVG builds upon many other successful standards such as XML (SVG graphics are text-based and thus easy to create), JPEG and PNG for image formats, DOM for scripting and interactivity, SMIL for animation and CSS for styling.

SVG is interoperable. The W3C release a test suite and implementation results to ensure conformance. Applications of SVG in industry are graphics platform for mobile phone, embedded system and print industry, web applications, design and interchange, GIS (Geographic Information Systems) and mapping, etc.

We adopt SVG files as the inter-media of Visual Authoring Process because SVG has above advantages. For example, we can preview the MMI in SVG files by web browser, and MMI programmers can add more information about MMI programs into SVG files conveniently. Furthermore, we can apply the functionality of XML parser to implement the specific SVG Parse very easily for the SVG files of MMI.

To simplify the implementation, we use three SVG elements, Layer, Rect and Text, to implement the MMI elements for storage systems. Please refer to the relationship between SVG elements and MMI elements in the following table. Using the same SVG element, we define one or more MMI elements with different attributes sot that we can manipulate them very conveniently in Generic MMI Engine.

Table 2. Implement MMI Elements by SVG Elements

SVG Elements MMI Elements

Layer Screen, Layer

Rect Rect, Edge

Text Text, Title, Head, Cont, Navi, Msg, Node

1) Using SVG Layer element to implement Screen, Layer MMI elements: The Layer Manger of Inkscape can control SVG Layer element to display or hide, free-to-modify or lock-up. We define Screen element to compose the base screen layout, and Layer element to place one menu and its related components, e.g. some items in this menu, or help messages for it.

2) Using SVG Rect element to implement Rect, Edige MMI elements: The rectangle in SVG graphics can be solid or hollow rectangles. We use solid rectangle to define Rect MMI element that is used for menu’s body and shadow, and hollow rectangle to define Edge MMI element that is the edge or border of menu’s body.

3) Using SVG Text element to implement Text, Title, Head, Cont, Navi, Msg, Node MMI elements: The SVG Text element has many attributes, like font size or color. We use the same font size for all text MMI elements. Nevertheless, we define many text MMI elements with different colors. They are used for different purposes: The Text MMI element is a common string and can be used in base screen layer. The Title MMI element is used for the title of base screen or menus. The Head MMI element is used for the head of items in menus.

The Cont MMI element is used for the content of items in menus. The Navi MMI element is used for the string on Navigation Bar. The Navigation Bar is the row between screen title and canvas and it can show the path of current menus. The Msg MMI element is used for the string on Message Bar. The Message Bar is the lowest row in screen and it can display the message for current menu. The latest and important MMI element, Node, can carry the information to child menu and the related function to take actions, but MMI programmers must add the child menu and related function for each Node manually.

3.3.3 SVG Parser

After using Inkscape to create SVG files, we need a parser to parse SVG structure and obtain required information from SVG files. We call this parser as SVG Parser. Before describe the SVG parser, we introduce the concept of XML DOM (Document Object Model) first.

In the right part of figure 16, it is a simple XML in plain text. This XML describes a bookstore with a couple of books.

Figure 16. XML in Plain Text

Each book has four elements: title, author, year and price. For example, first book’s title is “Everyday Italian” in English language, because its attribute is lang=”en”, author is

“Giada De Laurentiis”, year is 2005, price is 30.00. In the left part of figure 16, there is a tree to describe the hierarchy of that XML. It is very easy to understand compared with the plain text format.

Figure 17 illustrates a using example of XML DOM (Document Object Model) for the above XML of bookstore.

Figure 17. XML DOM

The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page..

Using XML DOM, a XML Parser can traverse the node tree, access the nodes and their attribute values, insert and delete nodes, and convert the node tree back to XML. In our implementation, we choose Expat XML Parser [19].

Expat is an XML parser library written in C. It is a stream-oriented parser in which an application registers handlers for things the parser might find in the XML document (like start tags).

In figure 18, it is a function reference for Expat XML Parser. Expat provides many functions for parsing XML.

Figure 18. Expat XML Parser

Actually, we implement our SVG Parser and just invoke the following functions of Expat XML Parser. They are summarized in Table 3.

Table 3. SVG Parser Uses Functions of Expat XML Parser

Function Name Description

XML_ParserCreate( ) Construct a new parser

XML_SetElementHandler( ) Set handlers for start and end tags XML_SetCharacterDataHandler( ) Set a text handler

XML_Parse( ) Parse some more of the document in a buffer

In the main function of SVG Parser, we invoke XML_ParserCreate( ) to construct a new XML parser, and invoke XML_SetElementHandler( ) to set handlers for SVG elements and XML_SetCharacterDataHandler( ) for element’s text processing. In the body of main functions, we allocate a buffer, use a loop to read a part of SVG file into this buffer, and invoke XML_Parser( ) to parse data repeatedly until the whole SVG file is processed.

3.3.4 MMI Data

The output of Visual Authoring Tool is SVG files. We use SVG Parser to get out the information from SVG files and store as MMI Data format. To simplify the usage of MMI Data, we implement the format of MMI Data in a C header file, and correspondent macros in the code of Generic MMI Engine.

To implement MMI elements, we define the following macros:

1) For Screen and Layer MMI elements, we define CREATE_SCREEN( ), END_OF_SCREEN( ), CREATE_LAYER( ), END_OF_LAYER( ) macros. Because Screen and Layer MMI elements can contain other MMI elements, we use CREATE_XXX( ) and END_OF_XXX( ) macros to clip them.

2) For Rect and Edge MMI elements, we define CREATE_RECT( ) and CREATE_EDGE( ) macros. These two macros need the attributes: name, X coordinate, Y coordinate, width, height, color of solid or hollow rectangles.

3) For Text-like MMI elements, we define CREATE_TEXT( ), CREATE_TITLE( ), CREATE_HEAD( ), CREATE_CONT( ), CREATE_NAVI( ), CREATE_MSG( ), CREATE_NODE( ) macros. For Text, Title, Head, Cont, Navi, Msg MMI elements, they need the attributes: name, X coordinate, Y coordinate, color and string. Besides the previous ones, Node MMI element needs two additional attributes: child menu, related function. The attribute, child menu, tells Generic MMI Engine which menu layer is combined to this node.

And the attribute, related function, invokes the functions in Generic MMI Engine to take the related actions for this node. The scenario is when users press this node, the related function will be invoked to do something and then the child menu will be popped up.

Figure 19 demonstrates a partial MMI Data in the output file of SVG Parser --MmiData.h.

Figure 19. MmiData.h – The Output File of SVG Parser

In this example, we know that the screen screen_BiosCU contains MMI elements:

rect_ClearScreen, rect_ScreenTitle, text_ScreenTitle, rect_NaviBar, rect_Canvas, edge_CanvasBorder, rect_MsgBar. The rect_ClearScreen is the first rectangle to clear the whole screen. The rect_ScreenTitle is the background of screen title, and the text_ScreenTitle is the string of screen title. The rect_NaviBar is the background of Navigation Bar. The rect_Canvas and edge_CanvasBorder form the area of canvas to place menus. The rect_MsgBar is the background of Message Bar.

About the display order of SVG elements, Inkscape draws the leading element first, and then draws the following elements in sequence. Therefore, the following elements overlap on the previous ones. In our implementation of Generic MMI Engine, we also use the same display order for MMI elements. Hence, the MMI element text_ScreenTitle is displayed over the rect_ScreenTitle.

On the other hand, the display order of graphic layers, Inkscape draws the lowest layer first, and then draws the upper layers one bye one. So, the upper layers overlap on the lowest

one. Generic MMI Engine also displays layers for MMI elements in the same order. Thus, the layer_1_MainMenu is displayed over the scree_BiosCU.

In the bottom half of figure 19, the menu layer layer_1_MainMenu contains MMI elements: rect_MainMenuClrNavi, navi_MainMenu, rect_MainMenuShadow, rect_MainMenuBody, edge_MainMenuBorder, title_MainMenu, node_CtrlInfo, node_PdMng, node_LdMng, node_DaMng, node_BgAct, node_EventLog, rect_MainMenuClrMsg, msg_MainMenu. The rect_MainMenuClrNavi is the background of navi_MainMenu. The navi_MainMenu is the string on Navi Bar for main menu. The rect_MainMenuShadow is the shadow of main menu’s body. The rect_MainMenuBody is the body of main menu. The edge_MainMenuBorder is the border of main menu’s body. The title_MainMenu is the title of main menu. The node_CtrlInfo is the first node of main menu, and its child menu is layer_2_CtrlInfo and related function is MmiAct_CtrlInfo( ). The node_PdMng is the second node of main menu, and its child menu is layer_2_PdMng and related function is MmiAct_PdMng( ). The node_LdMng, node_DaMng, node_BgAct, and node_EventLog are not functional nodes, so their child menu is layer_1_MainMenu and related function is MmiAct_Null( ). The rect_MainMenuClrMsg is the background of msg_MainMenu. The msg_MainMenu is the string on Msg Bar for main menu.

For the MMI Data in the format of MmiData.h, we write the macros for each MMI elements. The details of these macros are revealed in the following description:

1) For Screen MMI element, we use CREATE_SCREEN( ) and END_OF_SCREEN ( ) macros. The Screen MMI element can contain Rect, Edge, and Text MMI elements. Because

1) For Screen MMI element, we use CREATE_SCREEN( ) and END_OF_SCREEN ( ) macros. The Screen MMI element can contain Rect, Edge, and Text MMI elements. Because