82 lines
3.4 KiB
XML
82 lines
3.4 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
|
|
<ulink url="http://www.anjuta.org/">Anjuta IDE</ulink> project
|
|
wizzard that creates an empty module written in Vala, ready
|
|
to be configured and built. 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> 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 <filename>.glade</filename> 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 opened. 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 property set automatically.
|
|
</para>
|
|
</refsection>
|
|
</refentry>
|