87 lines
3.7 KiB
XML
87 lines
3.7 KiB
XML
<?xml version="1.0"?>
|
|
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
|
|
]>
|
|
<refentry id="adding-modules">
|
|
<refmeta>
|
|
<refentrytitle>Adding modules</refentrytitle>
|
|
<manvolnum>0</manvolnum>
|
|
<refmiscinfo>Hedera Library</refmiscinfo>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>Adding modules</refname>
|
|
<refpurpose>
|
|
How to add your own modules
|
|
</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsection id="first">
|
|
<title>Previous stage</title>
|
|
<para>
|
|
Before you can add a module, you have to create it. To do so,
|
|
the Hedera Library ships with an Anjuta IDE project wizzard
|
|
that creates an empty module written in Vala, almost ready
|
|
to build . If you won't be using the Anjuta IDE, you'll
|
|
have to work your way to a built module. More on that will be
|
|
covered in the section about the module creation on the Tutorials.
|
|
</para>
|
|
</refsection>
|
|
|
|
<refsection id="adding">
|
|
<title>Adding the module</title>
|
|
<para>
|
|
At this point, you should have a compiled module, this consisting
|
|
in a folder with the data (images, UI definitions, etc.) of the
|
|
module along with the dynamic library (a <filename>.so</filename>
|
|
file) that Hedera will link in runtime to load the module.
|
|
There can also be an optional query directory. It can also be the
|
|
single <filename>.so</filename>, due to that may be the module
|
|
developer has coded the UI creation or may be beacuse both the
|
|
module and its data were compiled in a single file.
|
|
</para>
|
|
<para>
|
|
To run the module in the hedera runtime you must set the environment
|
|
variable VN_MODULE_LIB_PATH to the full path to the module or
|
|
modules <filename>.so</filename> files (separated by :), and
|
|
VN_MODULE_DATA_PATH pointing to the <filename>.xml</filename>,
|
|
<filename>.glade</filename>, <filename>.ui</filename> and any
|
|
other data of the module, there is also an optional third variable,
|
|
VN_MODULE_QUERY_PATH that points to <filename>.sql</filename>
|
|
files. Once these variables are set you'll have to run
|
|
the Hedera application normally, and it will look for the
|
|
values on the variables and load the module. Note that if you use
|
|
the Anjuta IDE with the project created by the wizzard, as you run
|
|
in Anjuta the variables will be automatically set pointing to your
|
|
project files (if the project folder is changed, you'll need to
|
|
manually reset the variables in Anjuta).
|
|
</para>
|
|
</refsection>
|
|
|
|
<refsection id="forms">
|
|
<title>Expected form definition</title>
|
|
<para>
|
|
Each module can have any number of forms, that will be compiled
|
|
inside the same file. Independently from the form functionality,
|
|
each form needs to offer some things necesary for Hedera to
|
|
recognize and load it as expected.
|
|
</para>
|
|
<para>
|
|
The main of these requirements is to list the form in the
|
|
<filename>.xml</filename> file of the module. Also, the interface
|
|
description file must have the ".glade" extension and contain a
|
|
GtkContainer with the identifier "main" as the base widget, this
|
|
widget will be loaded inside a GtkNotebook and will be the first
|
|
thing the user will see when the form gets loaded. This glade file
|
|
may also contain a VnBatch with all the models needed by the form
|
|
and with the identifier "models", every model inside this batch will
|
|
get its connection set and a GtkActionGroup idenfitied by "actions"
|
|
containing the actions that will be used in the toolbar and the menu
|
|
of the main application. To actually get these actions in the
|
|
toolbar and menu of the application the programmer must provide a
|
|
file with the extension ".ui" containing a GtkUIManager definition
|
|
using the actions in the "actions" group.
|
|
</para>
|
|
</refsection>
|
|
</refentry>
|