aboutsummaryrefslogtreecommitdiffstats
path: root/MODULE_HACKING
blob: 4188c4a7655399e1d610c6e835dab6f825656c4d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
ManaTools Modules
======================================

mpan, ManaTools panel or Mageia Panel if you like,
is basically an application launcher, so everything
executable file can be run really. To get benefit of UI abstraction
though, the "modules" should be written with the use of libYUI, yast
user interface abstraction, so that they can be run using a  Gtk, ncurses
or Qt environment in a transparent manner.
Modules based on libYUi can be written in C++, using the native language,
python, ruby and perl, using libYUI bindings.

ManaTools is written in perl, so it also add a native approach,
for perl modules.

How to write a perl ManaTools module
======================================

ManaTools module are written using Moose wit an OO apporach.
Modules are extension of the ManaTools::Module class.

- Code alignment
As a simple code convention, we add the followin line at the
beginning of the file

# vim: set et ts=4 sw=4:

So that using vim we force to get tabs to be 4 characters
and considered as blanks, so please if you use another editor
and you want to include your code under manatools tree
keep this convention.

- POD
Then add POD to your file, we are trying to pass "make test"
and POD is one of the important tests.
It's not only a matter of test of course, having the manual
and a good documentation of the modules is mandatory.
Remember also that the code could/should be read and understood by
other people, so try to keep POD aligned.

- Internal declaration
Internal functions or methods are "_" predfixed, e.g.
sub _foo {
}

- Module template
Try to keep distinct the GUI layout and the module back-end. Since
the module is a configuration tool for the most, one thing is the
graphic user interface and another is a lower level interface. Such
an approach allows to use shared things also into other projects
that don't want to use YUI bindings for instance.

Meaning that you have to:
1. Define the package name usually like:
   package ManaTools::Module::MyModule;

2. Use Moose and yui, the first to extend Module the latter for libYUI
   bindings.

3. Extend ManaTools::Module defining a "start" method that has to be invocated
   by ManaTools.
   Other important things are icon and name attributes, please have look at other modules
   code and to Moose documentation.

4. Add the module to configuration file so that mpan can load it (see below).

Some share code is into ManaTools::Shared modules, such as Locales to manage localization
or Module back-ends for instance.

A module template example is into extras/module_templete/ directory, where
extras/module_templete/mana_mt is the example script that use and run
the module, while the module itself is
extras/module_templete/ManaTools/Module/ModuleTemplate.pm
The module just show a MessageBox and exit.

- ManaTools configuration (how to run a module)

mpan can be run using a "name" parameter and eventually by forcing a configuration
directory path where to find configuration files.
Default name is mpan, and the name by convention is the place in witch to find
configuration files under /etc.
So mpan will look for:
/etc/mpan/settings.conf
/etc/mpan/categories.conf
categories can also be searched under:
/etc/mpan/categories.conf.d/MyModule.conf

How to run modules is defined into categories.conf or alternatively
MyModule.conf under the related categories.conf.d.
Last method allows to write a Module that is not under the ManaTools
development tree, and easily install, load and run it using mpan.

Categories are icon buttons that can contain more modules, so to have
a old mcc view:
_______________
|C |          |
|A |          |
|T | Modules  |
|E |          |
|G.|          |
---------------
Layout can change in future though.

Let's see an example of a category configuration
<category>
    <title xml:lang="en">Hardware</title>
    <icon>/usr/share/icons/configuration_section.png</icon>
    <module>
        <class>ManaTools::Module::Services</class>
    </module>
    <module>
        <title xml:lang="en">Module name</title>
        <launcher>PATH/to/lunch/module</launcher>
        <icon>absolute/paht/to/module/icon</icon>
    </module>
</category>

Note that icon and logo elements could be absolute or relative
pathnames (e.g. no "/" as first char), if relative the absolute
pathname is evaluated as
File::ShareDir::dist_file(ManaTools::Shared::distName(), 'given/file').

First module is a perl ManaTools::Module extension (Services),
latter is an external one, called "module" and with a full pathname.

As you can see it could be a script, as well as an executable command.
Look at settings.conf and categories.conf for details.