[Ryzom Core] Ryzom GUI Editor

dfighter

Abstract

Ryzom has a very powerful and flexible GUI which can be configured from XML files. The XML GUI configuration files define the GUI layout, the widgets, and the data source for the widgets ( in reality it can only use the CDB system as a data source, but nevertheless the location of the data can be specified within the CDB and it's still a lot more flexible than having to fill the data with code ). This project involves extracting the GUI code from Ryzom and turning it into a reusable library, then building a GUI editor on top of it using the Qt framework. The editor shall be able to load existing GUI XML files and create new ones.

Additional Information

Deliverables
GUI library

  • Library code extracted and refactored from the client
  • Developer documentation, in the form of code comments, and
  • Functional overview
  • Integration instructions

 


GUI editor

  • GUI Editor OVQT plugin code,
  • Qt translation file(s)
  • Developer documentation in the form of code comments
  • User documentation with use case videos.

 
Project Details

GUI library
The basic idea is, that since the GUI code is tightly coupled with the Ryzom client, first it needs to be moved out of the client as a separate library.
For this first need to design this library, right now the masterplan is to have the library depend on a NEL3D driver that will serve as the output. The input will also be served by NEL, with an NLMISC eventserver. Since the GUI code supports Lua scripting, it will need to have Lua support too. One of the nice things about the Ryzom GUI is that instead of having to update it’s widgets with data in code, the widgets can update themselves with observing a database. Ryzom has the CDB as this database, but it’s Ryzom related and since we want the GUI to be separate of Ryzom there needs to be an abstract data source for this.

 

 

 

 

 

GUI editor
As we discussed with one of the mentors, the very least the editor should be able to load the already existing widgets from the XML files ( this shouldn’t be a problem as the code for this already exists ), render them, and create at least some basic widgets and then of course save them into XML files.
I intend to load the available widget types and properties from an XML definition file, that would allow a kind of inheritance, as the widgets use inheritance too. The base widgets have properties that the derived widgets inherit, just like in the Qt framework for example.
 
Example XML definitions:

 


<widgets>
<widget>
<name>SomeWidget</name>
<properties>
<property>
<name>property1</name>
<type>uint32</type>
<default>666</default>
</property>
<property>
<name>property2</name>
<type>bool</type>
<default>true</default>
</property>
</properties>
</widget>
<widget>
<name>SomeOtherWidget</name>
<properties>
<property>
<name>property2</name>
<type>uint64</type>
<default>1337</default>
</property>
<property>
<name>property2</name>
<type>bool</type>
<default>false</default>
</property>
</properties>
</widget>
</widgets>

 

The XML GUI files that should be loaded should be loaded from yet another XML file, that could serve as a kind of „project file” for the editor.
Example project file:

 

<interface_files>
<file>file1.xml</file>
<file>file2.xml</file>
<file>file3.xml</file>
<file>file4.xml</file>
</interface_files>

 


The editor should display, and make the widget hierarchy editable ( so we can add new widgets into the hierarchy or remove them, and also select a widget, activate it, etc ).
New widgets could be added using a context menu, there could be a „add widget” option which would list the available widgets and by selecting one of them a new widget would appear inside the container widget that the cursor points to currently ( or the operation would fail if there’s no container widget under the cursos ). Widget properties could be edited with a „standard” tree property editor widget.
The GUI code supports all kinds of goodies, like "procedure", "action handlers", "links", "variables", "defines".

A variable as the name suggests is a variable content storage, referencable by the GUI widgets.

A define is a constant value.

An action handler is basically a script that can be run from the GUI code, it can either be a Lua script, or a hardcoded script, it can accept conditions and parameters too.

A procedure is basically a batch of action handlers, that are executed one after another.

A link links certain conditions to GUI widgets, and or action handlers. When the condition becomes true, the action handler is run, or the GUI widget is activated.

The GUI editor should provide editing capabilities for these too.

 

 

 


 

 


Integrating the GUI editor with the GUI library
The GUI editor will be implemented as a OVQT plugin, with the Qt framework. Since Qt provides access to it’s eventloop events ( keyboard press, mouse click, paint events, etc ) with event handler calls, and OVQT provides NEL3D paintdevices it should be fairly straightforward. The input events can be injected into the GUI library and the output of the library can be attached to said paint device.

Code samples