]> SALOME platform Git repositories - samples/pyhello.git/blob - doc/input/index.doc
Salome HOME
Synchronize adm files
[samples/pyhello.git] / doc / input / index.doc
1 /*!
2
3 \mainpage Introduction to PYHELLO sample module
4
5 The purpose of the \b PYHELLO module is to describe briefly the different
6 steps in the development of a SALOME module in Python.
7
8 Contents:
9 - \subpage dev_steps
10 - \subpage tree_structure
11 - \subpage build_proc_files
12 - \subpage idl_dir
13 - \subpage src_dir
14 - \subpage bin_dir
15 - \subpage doc_dir
16 - \subpage build_procedure
17 - \subpage run_procedure
18 - \subpage load_module
19 - \subpage catalog_def
20 - \subpage load_lcc
21 - \subpage load_iapp
22
23 \ref dev_steps ">> Next"
24
25 \page dev_steps Steps in construction of the example module
26
27 The example module chosen to illustrate the process of SALOME module
28 development is extremely simple. The module contains a single
29 component and this component provides a single service called \b
30 makeBanner that accepts a character string as the sole argument and
31 that returns a character string obtained by the concatenation of a
32 'Hello' and the input string. The component also provides a simple
33 GUI.
34
35 The steps in the development are as follows:
36 - create a module tree structure
37 - create a SALOME component that can be loaded by a Python SALOME container
38 - configure the module so that the component is known to SALOME
39 - add a graphic GUI
40
41 \ref index "<< Previous"<br>\ref tree_structure ">> Next"
42
43 \page tree_structure Create the module tree structure
44
45 The first step in the development process is the creation of the
46 module tree file structure. The typical SALOME module usually includes
47 some set of the configuration files (used in the build procedure of a
48 module), Makefiles, IDL file that provides a definition of a CORBA
49 services implemented in a module and a set of source Python files
50 which implement the module CORBA engine and (optionally) its GUI.
51
52 The following file structure is typical for the SALOME module:
53
54 <pre>
55 + PYHELLO1_SRC
56    + CMakeLists.txt
57    + SalomePYHELLOConfig.cmake.in
58    + adm_local
59      + CMakeLists.txt
60      + cmake_files
61        + CMakeLists.txt
62        + FindSalomePYHELLO.cmake
63    + bin
64      + CMakeLists.txt
65      + VERSION.in
66      + runAppli.in
67      + myrunSalome.py
68    + idl
69      + CMakeLists.txt
70      + PYHELLO_Gen.idl
71    + src
72      + CMakeLists.txt
73      + PYHELLO
74        + CMakeLists.txt
75        + PYHELLO.py
76        + PYHELLO_utils.py
77      + PYHELLOGUI
78        + CMakeLists.txt
79        + PYHELLOGUI.py
80        + PYHELLO_msg_en.ts
81        + PYHELLO_msg_fr.ts
82        + PYHELLO_icons.ts
83    + resources
84      + CMakeLists.txt
85      + PYHELLO.png
86      + PYHELLO_small.png
87      + ExecPYHELLO.png
88      + handshake.png
89      + stop.png
90      + PYHELLOCatalog.xml.in
91      + SalomeApp.xml.in
92      + schema.xml
93    + doc
94      + CMakeLists.txt
95      + doxyfile.in
96      + index.doc
97 </pre>
98
99 Note that other files can be optionally present. For example, in some
100 SALOME modules sources tree you can find such files as AUTHORS,
101 INSTALL, ChangeLog, COPYING, NEWS, README, etc. Some files are
102 specific only for this PYHELLO sample module, for example PNG images
103 in the resources directory which are used in the GUI dialog boxes etc.
104
105 The usual way of the sources directory tree structure initial creation
106 is to copy it from the existing SALOME module.
107
108 \warning The files of the platform base module (KERNEL) must not be
109 copied to initialise a module tree structure. It is usually preferable
110 to copy files from another module such as GEOM or MED.
111
112 The module name is PYHELLO, the component name is PYHELLO and all the
113 files are put in a directory named PYHELLO1_SRC.
114 Below is a short description of these files. Note, that files with .in
115 suffix are the cmake templates from which the actual files are
116 generated during the build procedure.
117
118 - \c CMakeLists.txt
119
120 These files are input text files that contain the project parameters 
121 and describe the flow control of the build process in simple CMake language as 
122 a part of the build system based on CMake. These files define 
123 the build procedure, namely, compilation and installation rules such as compiler 
124 and linker options, installation destination folder, package version etc.
125
126 - \c adm_local
127
128 This directory contains additional administrative files used by the
129 build procedure.
130
131 - \c adm_local/cmake_files/FindSalomePYHELLO.cmake
132  
133 Some modules can need some external packages in order to compile and 
134 run properly. The usual approach is to write a special *.cmake file
135 for the purpose of finding a certain piece of software and to set it's
136 libraries, include files and definitions into appropriate variables so that
137 they can be used in the build process of another project.
138 It is possible to include the standard CMake detection modules (FindXyz.cmake files,
139 located in the standard CMake installation directory) or, if CMake does not provide
140 a search procedure for some required software, it is necessary to create *.cmake
141 module for each pre-requisite.
142
143 Also, it is good idea to create and distribute *.cmake file for the project being
144 developed; it can be used then in the dependent projects. For example, PYHELLO module
145 installs a file FindSalomePYHELLO.cmake that can be used for its detection.
146
147 To search SALOME PYHELLO module in some other project it will be only needed to write
148 the following code in CMakeLists.txt: 
149
150 \code
151 FIND_PACKAGE(SalomePYHELLO)
152 \endcode
153
154 - \c bin
155
156 This directory usually contains different scripts.
157
158 - bin/VERSION.in
159
160 This file is used to document the module, it must give its version (at
161 least) and (optionally) compatibilities or incompatibilities with
162 other modules. This file is strongly recommended but is not essential
163 for operation of the module.
164
165 - bin/runAppli.in
166 - bin/myrunSalome.py
167
168 These files are not essential but make the example easier to
169 use. These are scripts that can be used to run SALOME session with
170 PYHELLO module.
171
172 - \c idl
173
174 This directory contains IDL files that specify the CORBA services
175 supplied by SALOME module.
176
177 - idl/PYHELLO_Gen.idl
178
179 This is the CORBA IDL definition of the services implemented by SALOME
180 PYHELLO module.
181
182 - \c src
183
184 This is a root directory of the module source codes. Usually it contains
185 one or more sub-directories that provide an implementation of module
186 libraries, executables, Python API modules, etc. The hierarchy of the
187 sources tree is arbitrary; it follows the specific module needs.
188
189 - src/PYHELLO/PYHELLO.py
190 - src/PYHELLO/PYHELLO_utils.py
191
192 These files provide the implementation of a CORBA engine of the
193 PYHELLO module. In particular, this is an implementation of the 
194 services defined in the PYHELLO_Gen.idl file.
195
196 - src/PYHELLOGUI/PYHELLOGUI.py
197
198 The src/PYHELLOGUI is an optional directory that provides an
199 implementation of PYHELLO module's GUI. Strictly speaking, the
200 GUI is optional for each SALOME module. In some cases it's
201 enough to implement CORBA engine only. Then, the services of the
202 module will be avaiable in a CORBA environment. The module can be
203 loaded to the SALOME container and its services can be used in the
204 Supervisor computation schemas, in Python scripts or/and refer to it
205 in other modules. A GUI is necessary in the cases if it is planned to
206 access to the module functionality from the SALOME GUI session via
207 menu actions, dialog boxes and so on.
208
209 - src/PYHELLOGUI/PYHELLO_msg_en.ts
210 - src/PYHELLOGUI/PYHELLO_msg_fr.ts
211 - src/PYHELLOGUI/PYHELLO_icons.ts
212
213 These files provide a description (internationalization) of GUI
214 resources of the PYHELLO module. \c PYHELLO_msg_en.ts provides an English
215 translation of the string resources used in a module. \c PYHELLO_icons.ts
216 defines images and icons resources used within the GUI of the
217 PYHELLO module. Please refer to Qt linguist documentation for more
218 details.
219
220 - \c resources
221
222 This optional directory usually contains different resources files
223 required for the correct operation of SALOME module.
224
225 - resources/PYHELLO.png
226 - resources/PYHELLO_small.png
227 - resources/ExecPYHELLO.png
228 - resources/handshake.png
229 - resources/stop.png
230
231 The resources folder usually includes different resource files used
232 within the SALOME module. For example, PYHELLO.png file provides an icon
233 of PYHELLO module to be shown in the SALOME GUI desktop. ExecPYHELLO.png is
234 an icon for the makeBanner() function used in the menu and
235 toolbar. The icons handshake.png and stop.png are used in the dialog
236 boxes and PYHELLO_small.png icon is used to display in the Object
237 browser for root PYHELLO entity.
238
239 - resources/PYHELLOCatalog.xml.in
240
241 The XML description of the CORBA services provided by the PYHELLO
242 module. This file is parsed by Supervisor and YACS module to generate
243 the list of service nodes to be used in the calculation schemas. The
244 simplest way to create this file is to use Catalog Generator utility
245 provided by the SALOME KERNEL module, that can automatically generate
246 XML description file from the IDL file.
247
248 - resources/SalomeApp.xml.in
249
250 This file is essential for the module. It provides some parameters of
251 the module which define module behavior in SALOME. In particular it
252 should provide a section with the name corresponding to the name of a
253 module ("PYHELLO" in this case) with the following parameters:
254 \code
255   <section name="PYHELLO">
256     <parameter name="name"            value="PyHello"/>
257     <parameter name="icon"            value="PYHELLO.png"/>
258     <parameter name="library"         value="SalomePyQtGUI"/>
259     <parameter name="documentation"   value="pyhello_help"/>
260     <parameter name="version"         value="@SALOMEPYHELLO_VERSION@"/>
261   </section>
262 \endcode
263
264 The \a "name" parameter defines GUI name of a module. The \a "icon"
265 parameter defines a GUI icon of a module. The parameter \a "library"
266 specifies the name of the C++ library representing the front-end of
267 the module in the SALOME GUI desktop. The Python modules which do not
268 implement its own C++ front-end GUI library should specify
269 "SalomePyQtGUI" value in this parameter. The \a "documentation" parameter
270 provides a name for the help-related resource section (see below).
271 The \a "version" parameter defines the version of the module.
272
273 The section \a "resources" also specifies the directory that contains
274 resources of a module (icons, translation files, etc).
275
276 \code
277   <section name="resources">
278     <parameter name="PYHELLO" value="${PYHELLO_ROOT_DIR}/share/salome/resources/pyhello"/>
279   </section>
280 \endcode
281
282 The section \a "pyhello_help" provides information on the location of 
283 the help page and the eventual sub-menu in the Help menu.
284
285 \code
286   <section name="pyhello_help" >
287     <parameter name="sub_menu"        value="Samples"/>
288     <parameter name="%1 User's Guide" value="%PYHELLO_ROOT_DIR%/share/doc/salome/gui/PYHELLO/index.html"/>
289   </section>
290 \endcode
291
292 - doc/doxyfile.in
293
294 The Doxygen configuration file. The Doxygen is used to build this
295 documentation. The file doxyfile.in provides a rules for the
296 generation of module documentation.
297
298 - doc/index.doc
299
300 An input file for the Doxygen, which provides a source of this documentation.
301
302 - \c doc/images
303
304 This sub-folder contains images used in the documentation.
305
306 - \c doc/static
307
308 This sub-folder contains auxiliary files used when generating documentation
309 by Doxygen, like header (\c header.html.in) and footer (\c footer.html)
310 of the HTML pages, style sheet (\c doxygen.css) etc.
311
312 \ref dev_steps "<< Previous"<br>\ref build_proc_files ">> Next"
313
314 \page build_proc_files Build procedure input files
315
316 In most cases SALOME uses \b CMake-based build system for modules.
317 CMake is a cross-platform build system which works on Linux, Windows
318 and other operating systems.
319
320 The \c CMakeLists.txt files are used to describe the build procedure,
321 in particular:
322 - Test platform;
323 - Test system configuration;
324 - Detect pre-requisites;
325 - Generate build rules (for example, standard UNIX makefiles on Linux,
326   MSVC solutions, etc).
327
328 Project's root directory provides main CMake configuration that allows 
329 build all targets into one set of binaries and libraries. Each sub-directory
330 also includes CMake configuration file (CMakeLists.txt) that specifies
331 targets being build.
332
333 The file \c CMakeLists.txt in root directory of the PYHELLO module provides 
334 basic build rules to be used in other \c CMakeLists.txt files. 
335 It sets main properties of project: name, version, pre-requisites, 
336 installation paths, programming languages being used by the project,
337 tree of sub-directories, etc.
338
339 A lot of files used by the build procedure of HELLO module are located
340 in SALOME KERNEL module (that is referenced by the \c KERNEL_ROOT_DIR
341 environment variable), namely in its \c salome_adm sub-folder.
342 Similarly, the \c GUI_ROOT_DIR environment variable is used for the
343 graphical user interface (GUI) module of SALOME; this module also
344 provides a set of configuration utilities (\c *.cmake files) in its 
345 \c adm_local folder.
346
347 The files with an \c .in extension are the skeletons which are processed
348 by CMake to transform it to the resulting files in the build directory during
349 the configuration process.
350
351 \ref tree_structure "<< Previous"<br>\ref idl_dir ">> Next"
352
353 \page idl_dir The idl directory
354
355 The \c idl directory requires a \c CMakeLists.txt that must make the
356 compilation of the CORBA IDL \c PYHELLO_Gen.idl file and install all the
357 generated files into the correct module installation directories.
358 This is done by using \c OMNIORB_ADD_MODULE() CMake macro:
359
360 \code
361 OMNIORB_ADD_MODULE(SalomeIDLPYHELLO PYHELLO_Gen.idl ${KERNEL_ROOT_DIR}/idl/salome ${KERNEL_SalomeIDLKernel})
362 INSTALL(TARGETS SalomeIDLPYHELLO EXPORT ${PROJECT_NAME}TargetGroup DESTINATION ${SALOME_INSTALL_LIBS})
363 \endcode
364
365 The idl file itself must define a CORBA module for which the name must
366 be different from the module name to avoid name conflicts and define a
367 CORBA interface that is derived at least from the EngineComponent interface  
368 of the Engines module. The name of the CORBA module will be
369 \b PYHELLO_ORB and the name of the interface will be \b PYHELLO_Gen. 
370
371 \ref build_proc_files "<< Previous"<br>\ref src_dir ">> Next"
372
373 \page src_dir The src directory
374
375 The src contains all source files required to build and install CORBA
376 engine and (optionally) GUI of the module. Each of these entities usually
377 has (but this is not actually obligatory) its own directory.
378
379 The \c CMakeLists.txt file triggers the path of sub-directories described
380 by the \a ADD_SUBDIRECTORY() command.
381
382 - The src/PYHELLO directory
383
384 This directory contains the Python files that implement the engine
385 of the module. The \c CMakeLists.txt defines the rules used to install these
386 files to the destination folder. The name of the module
387 engine Python file is predefined and should be set as <MODULE>.py
388 where <MODULE> is a name of the module. In the case of the PYHELLO
389 module, the name of the engine Python script should be PYHELLO.so.
390
391 The \c PYHELLO.py Python script implements PYHELLO class that is derived
392 from the PYHELLO_Gen interface of the PYHELLO_ORB__POA CORBA module,
393 the SALOME_ComponentPy_i class (base implementation of SALOME
394 Python module engine exported by the KERNEL module) and
395 SALOME_DriverPy_i class that provides base implementation of
396 persistence mechanism.
397
398 In particular, \a PYHELLO class implements makeBanner() function that is
399 defined in the IDL interface PYHELLO_ORB::PYHELLO_Gen. 
400
401 \code
402 def makeBanner( self, name ):
403     banner = "Hello %s!" % name
404     return banner
405 \endcode
406
407 Other services
408 defined in PYHELLO_Gen CORBA interface also should be implemented by
409 this class.
410
411 - The src/PYHELLOGUI directory
412
413 This directory contains the Python files that implement the GUI
414 of PYHELLO module. The name of the module GUI Python script is
415 predefined and should be set as <MODULE>GUI.py where <MODULE> is a
416 name of the module. In the case of the PYHELLO module, the name of the
417 GUI Python script should be PYHELLOGUI.py.
418
419 The implementation of GUI of the PYHELLO module should be done
420 according to the architecture and rules specified by the SALOME GUI
421 module. The PYHELLO.py script should implement a set of the functions
422 which define the module behavior in GUI, for example, create menus,
423 toolbars, define context popup menus, objects selection behavior,
424 implement dialog boxes etc.
425  
426 Here below is a short description of these methods. For more details
427 please refer to the SALOME GUI module documentation.
428
429 - initialize() - module first initialization; usually used to create
430   GUI actions, menus, toolbars and so on;
431 - activate() - module activation; perform actions which should
432   be done when the module is activated by the user;
433 - deactivate() - module deactivation; perform actions which should
434   be done when the module is deactivated by the user;
435 - windows() - get a list and a position of the windows to be
436   associated with the module; these windows will be automatically
437   opened and positioned according to the setting defined by the value
438   returned by this function;
439 - views() - get a list of the compatible viewers; these viewers
440   will be automatically opened/raised on the module activation;
441 - createPopupMenu() - create and return context popup menu according
442   to the current selection;
443 - createPreferences() - initialize module's preferences;
444 - preferenceChanged() - callback function that is called when some
445   module's preference is changed by the user; allows to perform the
446   corresponding actions;
447 - engineIOR() - to get the reference to the module CORBA engine
448
449 Note, that some of these methods are optional and need not be
450 obligatory implemented because SalomePyQtGUI_Module class provides a
451 base implementation of these functions. It's sometimes enough to
452 implement only some of them, depending on the module needs.
453
454 In the case of PYHELLO module, some of these functions are
455 implemented to provide a sample for the development:
456
457 - engineIOR() that initializes PYHELLO module's eggine:
458
459 \code
460 def engineIOR():
461     IOR = ""
462     if getORB() and getEngine():
463         IOR = getORB().object_to_string( getEngine() )
464         pass
465     return IOR
466 \endcode
467
468 - initialize() that sets default module preferences
469
470 \code
471 def initialize():
472     if not sgPyQt.hasSetting( "PYHELLO", "def_obj_name"):
473         sgPyQt.addSetting( "PYHELLO", "def_obj_name", GUIcontext.DEFAULT_NAME )
474     if not sgPyQt.hasSetting( "PYHELLO", "creation_mode"):
475         sgPyQt.addSetting( "PYHELLO", "creation_mode", 0 )
476 \endcode
477
478 - createPreferences() that initializes module preferences for the
479  application's Preferences dialog box
480
481 \code
482 def createPreferences():
483     if verbose() : print "PYHELLOGUI.createPreferences() : study : %d" % _getStudyId()
484     gid = sgPyQt.addPreference( "General" )
485     gid = sgPyQt.addPreference( "Object creation", gid )
486     pid = sgPyQt.addPreference( "Default name",  gid, SalomePyQt.PT_String,   "PYHELLO", "def_obj_name" )
487     pid = sgPyQt.addPreference( "Default creation mode", gid, SalomePyQt.PT_Selector, "PYHELLO", "creation_mode" )
488     strings = QStringList()
489     strings.append( "Default name" )
490     strings.append( "Generate name" )
491     strings.append( "Ask name" )
492     indexes = []
493     indexes.append( QVariant(0) )
494     indexes.append( QVariant(1) )
495     indexes.append( QVariant(2) )
496     sgPyQt.setPreferenceProperty( pid, "strings", QVariant( strings ) )
497     sgPyQt.setPreferenceProperty( pid, "indexes", QVariant( indexes ) )
498     pass
499 \endcode
500
501 - windows() that defines dockable windows layout
502
503 \code
504 def windows():
505     if verbose() : print "PYHELLOGUI.windows() : study : %d" % _getStudyId()
506     wm = {}
507     wm[SalomePyQt.WT_ObjectBrowser] = Qt.LeftDockWidgetArea
508     wm[SalomePyQt.WT_PyConsole]     = Qt.BottomDockWidgetArea
509     return wm
510 \endcode
511
512 Please refer to PYHELLOGUI.py script for more details about
513 implementation of other callback functions.
514
515 An implemention of the ShowHello() function is quite simple. It shows
516 the small dialog box allowing user to enter the name, and then uses
517 reference to the module CORBA engine to invoke its makeBanner()
518 service.
519
520 Note, that GUI elements of the Python module are implemented with help
521 of PyQt toolkit which provides a Python wrappings of the Qt library.
522
523 \ref idl_dir "<< Previous"<br>\ref bin_dir ">> Next"
524
525 \page bin_dir The bin directory
526
527 The file VERSION.in is used to document the module, it must define its
528 version and (optionally) its compatibilities or incompatibilities with
529 other modules. Therefore, it is strongly recommended but is not
530 essential for correct operation of the module.
531
532 The runAppli.in file is the equivalent of the runSalome script
533 distributed by the KERNEL module but configured to start SALOME
534 session with PYHELLO module only.
535
536 The myrunSalome.py file reuses part of functionality provided by the
537 KERNEL's runSalome.py script. It is used to run SALOME session and
538 start PYHELLO module in this session. 
539
540 \ref src_dir "<< Previous"<br>\ref doc_dir ">> Next"
541
542 \page doc_dir The doc directory
543
544 This directory provides documentation files of the module. The
545 documentation of the module can be implemented in the arbitrary
546 way. But if you want your documentation to appear in the SALOME GUI
547 desktop's Help menu, some specific actions should be done as follows.
548
549 The documentation should be generated in the HTML format. For example,
550 the documentation of the PYHELLO module is generated using Doxygen
551 tool. It allows to generate structured set of HTML pages from the set
552 of input plain text files. Input source files should include Doxygen
553 tags and optionally direct HTML tags. For more details please refer to
554 the Doxygen documentation.
555
556 The resulting documentation of a module should include at least one
557 file index.html. All the HTML and image files should be exported by
558 the build procedure to the following directory:
559 <module_installation_dir>/share/doc/salome/gui/<MODULE>
560 where <module_installation_dir> is a module installation folder and
561 MODULE is its name. For example, for PYHELLO module, at least one file
562 should exist:
563 <PYHELLO_module_installation_dir>/share/doc/salome/gui/PYHELLO/index.html. 
564
565 The SALOME GUI automatically searches for the index.html file in the
566 mentioned module directory. If the file is found, the corresponding
567 menu command is automatically added to the Help menu of the SALOME GUI
568 desktop.
569
570 \ref bin_dir "<< Previous"<br>\ref build_procedure ">> Next"
571
572 \page build_procedure Construction, installation
573
574 Before building PYHELLO module, please ensure that SALOME environment is
575 set properly. Assume that SALOME environment is set in env_products.sh
576 script. In order to build and install PYHELLO module, you have to
577 perform several steps:
578
579 <pre>
580 [bash% ] source env_products.sh
581 [bash% ] mkdir PYHELLO_BUILD
582 [bash% ] cd PYHELLO_BUILD
583 [bash% ] cmake -DCMAKE_BUILD_TYPE=<Mode> -DCMAKE_INSTALL_PREFIX=<PYHELLO_module_installation_dir> ../PYHELLO1_SRC
584 [bash% ] make
585 [bash% ] make install
586 </pre>
587
588 The first command sets environment for building project.
589
590 Second command creates a build directory for the PYHELLO module. Then
591 next step is to cd to this build directory. From this directory you 
592 invoke cmake command, where <Mode> is build mode (Release or Debug),
593 <PYHELLO_module_installation_dir> is a destination folder to install PYHELLO module of SALOME.
594 By default (if CMAKE_INSTALL_PREFIX option is not given), PYHELLO module will be 
595 configured for installation to the /usr directory that requires root permissions 
596 to complete the installation. 
597
598 Next steps - build the package (\c make) and install it (\c make install). 
599
600 On each step, you have to ensure that the operation is finished correctly 
601 (no errors raised). After the last step is finished, the PYHELLO module is built
602 and installed to the \c \<PYHELLO_module_installation_dir\> directory.
603
604
605 \ref doc_dir "<< Previous"<br>\ref run_procedure ">> Next"
606
607 \page run_procedure Running SALOME
608
609 Go to the the <PYHELLO_module_installation_dir> directory and type:
610
611 <pre>
612 [bash% ] ./bin/salome/runAppli
613 </pre>
614
615 This command runs SALOME session configured for KERNEL and the PYHELLO
616 module. At the end of running, the user will be prompted by the
617 Python interpreter command line configured for SALOME that provides
618 access to SALOME Python API (including CORBA interfaces).
619
620 The runAppli file is a shell script that executes a Python commands
621 running SALOME session by passing arguments to it in a command line:
622         
623 <pre>
624 ${KERNEL_ROOT_DIR}/bin/salome/envSalome.py python -i $PYHELLO_ROOT_DIR/bin/salome/myrunSalome.py --modules=PYHELLO --killall
625 </pre>
626
627 These arguments state that the myrunSalome.py script located in the
628 PYHELLO module will be used, that the PYHELLO component will be
629 activated and all previously running SALOME sessions should be
630 shutdowned.
631
632 This command will not function unless the following environment
633 variables have previously been set:
634
635 <pre>
636 export KERNEL_ROOT_DIR=<KERNEL_module_installation_dir>
637 export PYHELLO_ROOT_DIR=<PYHELLO_module_installation_dir>
638 </pre>
639
640 \warning It is possible that the SALOME run will not reach the end.
641 In some circumstances, the time to start CORBA servers may be long and
642 could exceed the timeout. If the reasons is that the time to
643 load dynamic libraries is long, it is possible that a second run
644 immediately afterwards will be successful.
645  
646 \ref build_procedure "<< Previous"<br>\ref load_module ">> Next"
647
648 \page load_module Loading PYHELLO component
649
650 The PYHELLO_ORB module has to be imported before making a request to
651 load the component into the container, to obtain access to methods of
652 the component.  This container is made accessible in the myrunSalome.py
653 by means of the \b container variable:
654
655 <pre>
656 >> import PYHELLO_ORB
657 >> c=container.load_impl("PYHELLO","PYHELLO")
658 >> c.makeBanner("Christian")
659 </pre>
660
661 The last instruction returns a string "Hello Christian". Proceed as
662 follows to see the CORBA objects created by these actions:
663
664 <pre>
665 >> clt.showNS()
666 </pre>
667
668 \ref run_procedure "<< Previous"<br>\ref catalog_def ">> Next"
669
670 \page catalog_def PYHELLO module catalog definition
671
672 In the example from the previous chapter, the PYHELLO component was
673 loaded by making a direct request to the SALOME container. This is not
674 the standard method for loading of a component. The normal way uses
675 the SALOME LifeCycle service that invokes SALOME Module Catalog
676 services to identify the component and its properties and then calls
677 the requested container to load the component. 
678
679 Before this method can be used, the component must be declared in a
680 catalog in the XML format, for which the name must be
681 <Module>Catalog.xml. In our case, it will be PYHELLOCatalog.xml.
682 Usually this catalog is put to the resources sub-directory of the
683 directory tree. The simplest way to create this file is to use Catalog
684 Generator utility provided by the SALOME KERNEL module, that can
685 automatically generate XML description file from the IDL file.
686
687 \ref load_module "<< Previous"<br>\ref load_lcc ">> Next"
688
689 \page load_lcc Loading PYHELLO component via LifeCycle service
690
691 The method of loading the component is not very different from that
692 is described above. The services of the LifeCycle module are used in
693 this case instead of calling the container directly. The call sequence
694 is contained in the myrunSalome.py \b test() function.
695
696 <pre>
697     c=test(clt)
698     c.makeBanner("Christian")
699 </pre>
700
701 The test function creates the LifeCycle object. It then asks for the
702 PYHELLO component to be loaded in the FactoryServer container:
703
704 \code
705 def test(clt):
706     """
707     Test function that creates an instance of PYHELLO component
708     usage : hello=test(clt)
709     """
710     import LifeCycleCORBA
711     lcc = LifeCycleCORBA.LifeCycleCORBA(clt.orb)
712     import PYHELLO_ORB
713     pyhello = lcc.FindOrLoadComponent("FactoryServePy", "PYHELLO")
714     return pyhello
715 \endcode
716
717 \ref catalog_def "<< Previous"<br>\ref load_iapp ">> Next"
718
719 \page load_iapp Loading from the GUI (IAPP)
720
721 In order to activate PYHELLO module in the SALOME GUI desktop, the user
722 should press the PYHELLO module's button on the "Modules" toolbar or
723 select the name of the module in the combo box on this toolbar.
724
725 The image file to be used as an icon of a module should be exported by
726 the module build procedure. The icon file name is defined in the
727 corresponding SalomeApp.xml configuration file:
728 \code
729   <section name="PYHELLO">
730     <parameter name="name" value="Hello"/>
731     <parameter name="icon" value="PYHELLO.png"/>
732     <parameter name="library" value="SalomePyQtGUI"/>
733   </section>
734 \endcode
735
736 \ref load_lcc "<< Previous"
737
738 */