if not os.path.exists(module_lib_py_dir):
print "Python directory %s does not exist" % module_lib_py_dir
else:
+ # __GBO__ specific action for the package salome
+ module_lib_pypkg_dir=os.path.join(module_lib_py_dir,"salome")
+ lib_pypkg_dir=os.path.join(lib_py_dir,"salome")
+ mkdir(lib_pypkg_dir)
+ # __GBO__
mkdir(lib_py_shared_dir)
for fn in os.listdir(module_lib_py_dir):
if fn == "shared_modules": continue
+ # __GBO__
+ if fn == "salome": continue
+ # __GBO__
symlink(os.path.join(module_lib_py_dir, fn), os.path.join(lib_py_dir, fn))
pass
if os.path.exists(module_lib_py_shared_dir):
symlink(os.path.join(module_lib_py_shared_dir, fn), os.path.join(lib_py_shared_dir, fn))
pass
pass
+ # __GBO__
+ if os.path.exists(module_lib_pypkg_dir):
+ for fn in os.listdir(module_lib_pypkg_dir):
+ symlink(os.path.join(module_lib_pypkg_dir, fn), os.path.join(lib_pypkg_dir, fn))
+ pass
+ pass
+ # __GBO__
else:
if verbose:
print module_lib_py_shared_dir, " doesn't exist"
AC_ENABLE_PRODUCTION(no)
AC_ENABLE_MPI_SEQ_CONTAINER(no)
+# _GBO_SALOME_PYTHON_PACKAGING_
+PYLOGLEVEL=DEBUG
+AC_SUBST(PYLOGLEVEL)
+
echo
echo ---------------------------------------------
echo testing libtool
dnl add library libm :
AC_CHECK_LIB(m,ceil)
-# _CS_gbo We should add all dependent libraries
-
AC_CXX_USE_STD_IOSTREAM
AC_CXX_HAVE_SSTREAM
echo ---------------------------------------------
echo
-dnl _CS_gbo We should use here a variable given from the CHECK_PYTHON
-AM_PATH_PYTHON(2.3)
+# _GBO_ This definition is required. Without this definition, the pythondir
+# would not be defined. The version doesn't matter.
+AM_PATH_PYTHON(2.4)
CHECK_SWIG
echo
# Additional conditional to avoid compilation of non-portable code
AM_CONDITIONAL(WINDOWS, [ test ])
+echo
+echo ---------------------------------------------
+echo testing sphinx
+echo ---------------------------------------------
+echo
+CHECK_SPHINX
+
echo
echo ============================================================
echo Summary
echo
fi
-htmldoc_products="doxygen_ok graphviz_ok rst2html_ok"
+htmldoc_products="doxygen_ok graphviz_ok rst2html_ok sphinx_ok"
echo --- Html documentation products: only required for doc production
summary $htmldoc_products
doc/salome/gui/Makefile \
doc/salome/gui/doxyfile \
doc/salome/gui/static/header.html \
+ doc/docutils/Makefile \
idl/Makefile \
idl/Calcium_Ports.idl \
resources/Makefile \
src/GenericObj/Makefile \
src/HDFPersist/Makefile \
src/KERNEL_PY/Makefile \
+ src/KERNEL_PY/kernel/Makefile \
+ src/KERNEL_PY/kernel/logconfig.py \
src/Launcher/Makefile \
src/LifeCycleCORBA/Makefile \
src/LifeCycleCORBA/Test/Makefile \
+++ /dev/null
-=================================================================
-Installation instructions, up to date for 3.0 version
-=================================================================
-
-*html version of this document is produced with docutils*::
-
- rst2html < doc.txt > doc.html
-
-*This document corresponds to SALOME2 2.2.9.*
-*IT IS NOT UP TO DATE with 3.2.0*
-
-.. contents::
-.. sectnum::
-
-+-------------------------------------------+
-| **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
-+-------------------------------------------+
-
--------------------------------------------------------------------------------
-
-You'll find here generic instructions for installing the SALOME2 platform.
-
-Summary
--------
-
-`1. Quick Overview`_
-
-`2. System configuration`_
-
-`3. Third-party dependencies`_
-
-`4. Preparing the shell environment`_
-
-`5. Installing the KERNEL component`_
-
-`6. Installing the SALOME components`_
-
-`7. Runtime`_
-
-`8. Suggestions and advices`_
-
-
-1. Quick Overview
------------------
-
-First of all, you have to check (or install if needed) the dependant
-software programs on your system. These programs are:
-
-- common development tools as gcc, automake, autoconf and libtools.
-- third party softwares used in SALOME building or runtime process
- (python, OCC, VTK, ...)
-
-Further details can be found in sections [2] and [3].
-
-If the dependencies are installed on your system, then you have to set
-your shell environment to get access to the software components
-(cf. [4]. "Preparing the shell environment").
-
-The next step is to install the KERNEL (cf. [5] "Installing KERNEL"):
-
-::
-
-$ mkdir <kernel_build>
-$ mkdir <kernel_install>
-$ cd <kernel_src>
-$ ./build_configure
-$ cd <kernel_build>
-$ <kernel_src>/configure --prefix=<kernel_install>
-$ make
-$ make install
-
-Then, the SALOME components GEOM, MED, VISU, ... can be installed
-with a similar procedure (cf. [6]).
-
-Eventually, the platform can be run by executing the shell script
-runSalome (cf. [7]). Here, somme additionnal variables have to be set
-to describe the SALOME runtime configuration (<COMPONENT>_ROOT_DIR,
-OMNIORB_CONFIG)
-
-The following provides you with specific instructions for each step.
-
-
-2. System configuration
------------------------
-
-SALOME is compiled and tested on differents platforms with native packages:
-- Debian sarge
-- Mandrake 10.1
-- ...
-
-If you have another platform, we suggest the following configuration
-for building process:
-
-- gcc-3.3.x or 3.4.x
-- automake-1.7 or more (only aclocal is used)
-- autoconf-2.59
-- libtool-1.5.6
-
-remarks:
-
-- This is the minimum level of automake, autoconf and libtool, if you need
- to compile all the third party softwares (included OpenCascade 5.2.x).
-
-3. Third-party dependencies
----------------------------
-
-The SALOME platform relies on a set of third-party softwares. The
-current version depends on the following list
-(versions given here are from Debian Sarge, except OpenCascade, VTK and MED,
-which are not Debian packages):
-
-CAS-5.2.4 OpenCascade (try binaries,a source patch is needed)
-VTK-4.2.6 VTK 3D-viewer
-PyQt-3.13 Python-Qt Wrapper
-Python-2.3.5 Python interpreter
-SWIG-1.3.24 SWIG library
-boost-1_32_0 C++ library (only include templates are used)
-hdf5-1.6.2 Files Database library
-med-2.2.2 MED Data Format support for file records
-omniORB-4.0.5 ORB used in SALOME
-qt-x11-free-3.3.3 Qt library
-qwt-4.2 Graph components for Qt
-sip4-4.1.1 langage binding software
-
-And, in order to build the documentation:
-
-doxygen-1.4.2
-graphviz-2.2.1
-
-
-Additionnal software may be installed for optional features:
-
-netgen4.3 + patch
-tix8.1.4
-openpbs-2.3.16
-lsf-???
-
-
-
-3.1 To Do
-~~~~~~~~~
-- Instructions for installing these software programs can be found in a
- special note doc/configuration_examples/install-prerequis.
-- Installation shell scripts are also provided.
- These scripts have to be adapted to your own configuration.
-
-- See doc/configuration_examples/*
-
-In the following, we assume that all the third-party softwares are
-installed in the same root directory, named <salomeroot>/prerequis.
-Then, your file system should probably look like::
-
- <salomeroot>/prerequis/Python-2.2.2
- <salomeroot>/prerequis/omniORB-3.0.5
- <salomeroot>/prerequis/qt-x11-free-3.0.5
- ...
-
-
-4. Preparing the shell environment
-----------------------------------
-
-Some variables have to be set to get acces to third-party software
-components (include files, executable, library, ...) during building
-process and runtime.
-
-The shell file prerequis.sh, embedded in the KERNEL source package,
-provides a template for setting those variables. In this example, all the
-softwares are supposed to be installed in the same root directory,
-named here INSTALLROOT.
-
-Copy the prerequis.sh in a working directory and adjust the settings
-to your own configuration. To get the shell prepared, just
-execute the following command in the building shell:
-
-$ source prerequis.sh
-
-(we assume here a ksh or bash mode)
-
-
-5. Installing the KERNEL component
-----------------------------------
-
-We use here the notation <kernel_src> to specify the source directory
-of the KERNEL component. The shell environment is supposed to have
-been set (cf. 4).
-
-Installing the KERNEL from a source package needs three directories:
-
-- the source directory, denoted here by <kernel_src>.
-
-- the build directory, denoted by <kernel_build> in the following. This
- directory can't be the same directory as <kernel_src>.
-
-- the install directory, denoted by <kernel_install> in the following. This
- directory can't be the same directory as <kernel_src> or
- <kernel_build>.
-
-The installing process is:
-
-STEP 1:
- preparing directories
-
- create the <kernel_build> and the <kernel_install> directories::
-
- $ mkdir <kernel_build>
- $ mkdir <kernel_install>
-
-STEP 2:
- build configure script
-
- go to <kernel_src> directory and generate the "configure" script::
-
- $ cd <kernel_src>
- $ ./build_configure
-
- If it doesn't work, check your system automake tools as specified in
- section [2].
-
-STEP 3:
- configure the building process
- go to the build directory and execute the configuration process::
-
- $ cd <kernel_build>
- $ <kernel_src>/configure --prefix=<kernel_install>
-
- Note that <kernel_install> must be an absolute path.
-
- When the configure process is complete, check the status of
- third-party softwares detection. You should have a status like::
-
- ---------------------------------------------
- Summary
- ---------------------------------------------
- Configure
- cc : yes
- boost : yes
- lex_yacc : yes
- python : yes
- swig : yes
- threads : yes
- OpenGL : yes
- qt : yes
- vtk : yes
- hdf5 : yes
- med2 : yes
- omniORB : yes
- occ : yes
- sip : yes
- pyqt : yes
- qwt : yes
- doxygen : yes
- graphviz : no
- openpbs : no
- lsf : no
- Default ORB : omniORB
- ----------------------------------------------
-
-If a software get a status "no", then it's not "seen" in the system:
-
-- the software is not installed, or
-- the shell environment is not set correctly.
-
-In this example, the software programs graphviz, openpbs and lsf are not
-installed (optional for most usages).
-
-
-STEP 4 :
- Building the binary files
-
- Execute make in the <kernel_build> directory::
-
- $ make
-
-
-STEP 5:
- Installing binary files, scripts and documentation
-
- Execute install target in the <kernel_build> directory::
-
- $ make install
-
-
-6. Installing the SALOME components
------------------------------------
-
-TInstalling a component <COMPONENT> is done by following the same
-instructions as given for the KERNEL, replacing KERNEL by
-<COMPONENT> (build_configure, configure, make, make install).
-
-You just have to be aware of the dependencies between components:
-
-- MED depends on KERNEL
-- GEOM depends on KERNEL
-- SMESH depends on KERNEL, MED, GEOM
-- VISU depends on KERNEL, MED
-- SUPERV depends on KERNEL
-
-For example, installing the component SMESH needs the previous
-installation of the KERNEL component, and then the GEOM and MED components.
-
-The building process uses the variables <COMPONENT>_ROOT_DIR to
-localize the dependant components. The variables must be set to the
-install path directory of the components <COMPONENT> (ex:
-KERNEL_ROOT_DIR=<kernel_install>).
-
-In the above example, the three variables KERNEL_ROOT_DIR,
-GEOM_ROOT_DIR and MED_ROOT_DIR have to be set before configuring the
-building process of the SMESH component (STEP 3).
-
-
-7. Runtime
-----------
-
-See SALOME_Application_ to define your own configuration of SALOME and run it
-on one or several computers. This is the recommended way of configuration.
-
-.. _SALOME_Application: ./SALOME_Application.html
-
-The following explains the general principles.
-
-To run the SALOME platform, the procedure is:
-
-- set the shell environment to get acces to third-party softwares::
-
- $ source prerequis.sh
-
-- define the SALOME configuration by setting the whole set of
- variables <COMPONENT>_ROOT_DIR. Here, you just have to set the
- kernel and the components you need::
-
- $ export KERNEL_ROOT_DIR=<kernel_install>
- $ export MED_ROOT_DIR=<med_install>
- $ ...
-
-- define the CORBA configuration file by setting the variable
- OMNIORB_CONFIG. This variable must be set to a writable file
- path. The file may be arbitrary chosen and doesn't need to exist
- before running. We suggest::
-
- $ export OMNIORB_CONFIG=$HOME/.omniORB.cfg
-
-- run the SALOME platform by executing the script runSalome::
-
- $KERNEL_ROOT_DIR/bin/salome/runSalome
-
-
-8. Suggestions and advices
---------------------------
-
-For convenience or customization, we suggest the following organisation:
-
-- chose and create a root directory for the SALOME platform, say
- <salomeroot>.
-
-- install the third-party softwares in a sub-directory "prerequis"
-
-- install the SALOME components in a sub-directory "SALOME2"
-
-- make personnal copies of the files prerequis.sh and runSalome in
- <salomeroot>::
-
- $ cp <kernel_src>/prerequis.sh <rundir>/.
- $ cp <kernel_install>/bin/salome/runSalome <rundir>/.
-
- Edit the file prerequis.sh and adjust it to your own configuration.
-
-- define the SALOME2 configuration
-
- This step consists in setting the KERNEL_ROOT_DIR, the whole set of
- variables <COMPONENT>_ROOT_DIR you need, and the OMNIORB_CONFIG
- variable.
-
- We suggest to create a shell file envSalome.sh containing those
- settings. Then the configuration consists in loading envSalome.sh in
- the runtime shell::
-
- $ source envSalome.sh
-
-- When installed with this file organisation, running SALOME is done
- with the following shell commands::
-
- $ source <salomeroot>/prerequis.sh
- $ source <salomeroot>/envSalome.sh
- $ ./runSalome
-
-
--------------------------------------------------------------------------------
-
-+----------------------------------+------------------------------------------+
-| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ |
-+----------------------------------+------------------------------------------+
-
-.. _`General KERNEL documentation`: ./index.html
-.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html
+++ /dev/null
-=================================================================
-KERNEL Services for end user (Python interface)
-=================================================================
-
-*html version of this document is produced with docutils*::
-
- rst2html < doc.txt > doc.html
-
-This document corresponds to SALOME2 3.2.0
-
-.. contents::
-.. sectnum::
-
-+-------------------------------------------+
-| **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
-+-------------------------------------------+
-
--------------------------------------------------------------------------------
-
-In a SALOME application, distributed components, servers and clients use
-the CORBA middleware for comunication. CORBA interfaces are defined via idl
-files. All the different CORBA interfaces are available for users in Python,
-see CORBA interfaces below.
-
-For some general purpose services, CORBA interfaces have been encapsulated
-in order to provide a simple interface (encapsulation is generally done in
-C++ classes, and a Python SWIG interface is also generated from C++, to
-ensure a consistent behavior between C++ modules and Python modules or user
-script).
-
-General purpose services
-========================
-
-SALOME services access from a Python shell
-------------------------------------------
-See SALOME_Application_ for detailed instructions to launch a Python
-interpreter with full acces to the SALOME environment and services.
-
-.. _SALOME_Application: ./SALOME_Application.txt
-
-You can use the embedded Python interpreter in Grahic User Interface, or an
-external interpreter, with::
-
- ./runSession
- python
-
-In either cases, SALOME services access is done with::
-
- import salome
- salome.salome_init()
-
-In the embedded interpreter, it is already done, but there is no problem to
-do it several times, so it is preferable to add these instructions
-systematically in your scripts, to allow them to work in all configurations.
-
-Container and component instanciation
--------------------------------------
-
-See LifeCycleCORBA_ for the C++ interface (Python interface obtained with SWIG
-is very similar).
-
-.. _LifeCycleCORBA: ./tui/KERNEL/classSALOME__LifeCycleCORBA.html
-
-
-In the following example, a test component provided in KERNEL is launched
-in the local container, "FactoryServer", created when SALOME starts::
-
- import salome
- salome.salome_init()
-
- import LifeCycleCORBA
- lcc = LifeCycleCORBA.LifeCycleCORBA()
- obj=lcc.FindOrLoad_Component("FactoryServer","SalomeTestComponent")
-
- import Engines
- comp=obj._narrow(Engines.TestComponent)
-
- comp.Coucou(1)
-
-The answer is something like::
-
- 'TestComponent_i : L = 1'
-
-The _narrow() instruction is not always mandatory in Python, but sometimes
-useful to be sure you have got the right type of object. Here, Testcomponent_
-interface is defined in CORBA module Engines. With this example, it works also
-without the _narrow() instruction::
-
- obj.Coucou(1)
-
-.. _Testcomponent: ./tui/KERNEL/interfaceEngines_1_1TestComponent.html
-
-
-In the next example, a component instance is created in a specific Container
-defined by it's computer hostname and it's name. Here we use the local
-computer. Note that in Utils_Identity_, getShortHostName() gives the short
-hostname of the computer, without domain suffixes, which is used in SALOME.
-The container process is created here if it does not exists, and a new
-component instance is created::
-
- import salome
- salome.salome_init()
- import LifeCycleCORBA
- lcc = LifeCycleCORBA.LifeCycleCORBA()
-
- import Utils_Identity
- host = Utils_Identity.getShortHostName()
-
- import Engines
- params={}
- params['hostname']=host
- params['container_name']='myContainer'
- comp=lcc.LoadComponent(params,'SalomeTestComponent')
- comp.Coucou(1)
-
-.. _Utils_Identity: ./tui/KERNEL/namespaceUtils__Identity.html
-
-If you want to get a list of containers and component instances, client object
-from orbmodule_ provides a list::
-
- import orbmodule
- clt=orbmodule.client()
- clt.showNS()
-
-.. _orbmodule: ./tui/KERNEL/classorbmodule_1_1client.html
-
-The list looks like::
-
- Logger.
- ContainerManager.object
- Containers.dir
- cli70ac.dir
- FactoryServerPy.object
- SuperVisionContainer.object
- FactoryServer.object
- FactoryServer.dir
- SalomeTestComponent_inst_1.object
- myContainer.object
- myContainer.dir
- SalomeTestComponent_inst_1.object
- SalomeTestComponent_inst_2.object
- Registry.object
- Kernel.dir
- ModulCatalog.object
- Session.object
- Study.dir
- Study2.object
- extStudy_1.object
- extStudy_2.object
- extStudy_3.object
- myStudyManager.object
- SalomeAppEngine.object
-
-
-File transfer service
----------------------
-
-See FileTransferCORBA_ for the C++ interface (Python interface obtained with
-SWIG is very similar).
-
-.. _FileTransferCORBA: ./tui/KERNEL/classSALOME__FileTransferCORBA.html
-
-The following example shows how to tranfer a file from a remote host to the
-client computer. Remote hostname is 'cli76cc', we would like to copy
-'tkcvs_8_0_3.tar.gz' from remote to local computer. A full pathname is
-required. A container is created on remote computer if it does not exist,
-to handle the file transfer::
-
- import salome
- salome.salome_init()
-
- import LifeCycleCORBA
- remotefile="/home/prascle/tkcvs_8_0_3.tar.gz"
- aFileTransfer=LifeCycleCORBA.SALOME_FileTransferCORBA('cli76cc',remotefile)
- localFile=aFileTransfer.getLocalFile()
-
-
-CORBA Naming service access
----------------------------
-
-See SALOME_NamingService_ for the C++ interface. The Python interface
-SALOME_NamingServicePy_ is not yet derived from the C++ interface and offers
-only the most useful functions.
-
-.. _SALOME_NamingService: ./tui/KERNEL/classSALOME__NamingService.html
-.. _SALOME_NamingServicePy: ./tui/KERNEL/classSALOME__NamingServicePy_1_1SALOME__NamingServicePy__i.html
-
-Batch services
---------------
-
-See Batch_ documentation (in french only).
-
-.. _Batch: ./Batch.html/index.html
-
-All IDL Interfaces
-==================
-
-Containers and component life cycle, File transfer service
-----------------------------------------------------------
-
-+-----------------------------+-----------------------------------------------+
-| Engines_ | Engines CORBA module. |
-+=============================+===============================================+
-| Component_ | Generic component interface. |
-| | All SALOME components inherit this interface |
-+-----------------------------+-----------------------------------------------+
-| Container_ | Container: host for C++ and Python components |
-| | components instances |
-+-----------------------------+-----------------------------------------------+
-| FileTransfer_ | Agent for file transfer created by a container|
-| | copy a local file to a distent client |
-+-----------------------------+-----------------------------------------------+
-| FileRef_ | Reference to a file, used by a container for |
-| | file transfers |
-+-----------------------------+-----------------------------------------------+
-| ContainerManager_ | Unique instance, in charge of container |
-| | creation on remote computers |
-+-----------------------------+-----------------------------------------------+
-| MPIContainer_ | An exemple of parallel implementation for |
-| | containers and components |
-+-----------------------------+-----------------------------------------------+
-| MPIObject_ | |
-+-----------------------------+-----------------------------------------------+
-
-Study management
-----------------
-
-+-----------------------------+-----------------------------------------------+
-| SALOMEDS_ | SALOMEDS CORBA module |
-+=============================+===============================================+
-| SALOMEDSidl_ | |
-+-----------------------------+-----------------------------------------------+
-| SALOMEDS_Attributes_ | |
-+-----------------------------+-----------------------------------------------+
-
-High speed transfer, object life cycle, exceptions, GUI interface...
---------------------------------------------------------------------
-
-+-----------------------------+-----------------------------------------------+
-| SALOME_ | SALOME CORBA module |
-+=============================+===============================================+
-| SALOME_Comm_ | |
-+-----------------------------+-----------------------------------------------+
-| SALOME_GenericObj_ | |
-+-----------------------------+-----------------------------------------------+
-| SALOME_Exception_ | |
-+-----------------------------+-----------------------------------------------+
-| SALOME_Session_ | |
-+-----------------------------+-----------------------------------------------+
-
-Miscelleanous
--------------
-+-----------------------------+-----------------------------------------------+
-| | other CORBA modules |
-+=============================+===============================================+
-| SALOME_ModuleCatalog_ | |
-+-----------------------------+-----------------------------------------------+
-| SALOME_RessourcesCatalog_ | |
-+-----------------------------+-----------------------------------------------+
-| SALOME_Registry_ | |
-+-----------------------------+-----------------------------------------------+
-| Logger_ | |
-+-----------------------------+-----------------------------------------------+
-
-**Other idl for test purposes**
-nstest.idl
-SALOME_TestComponent.idl
-SALOME_TestModuleCatalog.idl
-SALOME_TestMPIComponent.idl
-TestNotif.idl
-
-.. _Engines: ./tui/KERNEL/namespaceEngines.html
-.. _Component: ./tui/KERNEL/interfaceEngines_1_1Component.html
-.. _Container: ./tui/KERNEL/interfaceEngines_1_1Container.html
-.. _fileTransfer: ./tui/KERNEL/interfaceEngines_1_1fileTransfer.html
-.. _fileRef: ./tui/KERNEL/interfaceEngines_1_1fileRef.html
-.. _ContainerManager: ./tui/KERNEL/interfaceEngines_1_1ContainerManager.html
-.. _MPIContainer: ./tui/KERNEL/interfaceEngines_1_1MPIContainer.html
-.. _MPIObject: ./tui/KERNEL/interfaceEngines_1_1MPIObject.html
-.. _SALOME: ./tui/KERNEL/namespaceSALOME.html
-.. _SALOMEDS: ./tui/KERNEL/namespaceSALOMEDS.html
-.. _SALOME_Component: ./tui/KERNEL/SALOME__Component_8idl.html
-.. _SALOME_ContainerManager: ./tui/KERNEL/SALOME__ContainerManager_8idl.html
-.. _SALOMEDSidl: ./tui/KERNEL/SALOMEDS_8idl.html
-.. _SALOMEDS_Attributes: ./tui/KERNEL/SALOMEDS__Attributes_8idl.html
-.. _SALOME_ModuleCatalog: ./tui/KERNEL/SALOME__ModuleCatalog_8idl.html
-.. _SALOME_RessourcesCatalog: ./tui/KERNEL/SALOME__RessourcesCatalog_8idl.html
-.. _SALOME_Registry: ./tui/KERNEL/SALOME__Registry_8idl.html
-.. _Logger: ./tui/KERNEL/Logger_8idl.html
-.. _SALOME_Comm: ./tui/KERNEL/SALOME__Comm_8idl.html
-.. _SALOME_GenericObj: ./tui/KERNEL/SALOME__GenericObj_8idl.html
-.. _SALOME_Exception: ./tui/KERNEL/SALOME__Exception_8idl.html
-.. _SALOME_Session: ./tui/KERNEL/SALOME__Session_8idl.html
-.. _SALOME_MPIContainer: ./tui/KERNEL/SALOME__MPIContainer_8idl.html
-.. _SALOME_MPIObject: ./tui/KERNEL/SALOME__MPIObject_8idl.html
-
-
--------------------------------------------------------------------------------
-
-+----------------------------------+------------------------------------------+
-| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ |
-+----------------------------------+------------------------------------------+
-
-.. _`General KERNEL documentation`: ./index.html
-.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html
#
include $(top_srcdir)/salome_adm/unix/make_common_starter.am
-SUBDIRS = salome
+SUBDIRS = salome docutils
docs: usr_docs
+++ /dev/null
-======================================================================
-SALOME Application Concept. Configuration for one or more computers
-======================================================================
-
-*html version of this document is produced with docutils*::
-
- rst2html doc.txt > doc.html
-
-This document corresponds to SALOME2 3.2.0
-
-.. contents::
-.. sectnum::
-
-+-------------------------------------------+
-| **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
-+-------------------------------------------+
-
--------------------------------------------------------------------------------
-
-The following explains how to configure your own application with your list of
-modules, how to define and run this application on one or more computers.
-
-General principles
-------------------
-
-A SALOME application is defined by a set of modules (GEOM, SMESH, ASTER...).
-
-A SALOME User can define several SALOME Applications. These applications are
-runnable from the same user account. These applications may share the same
-KERNEL and modules. Thus, the application configuration is independant of
-KERNEL and must not be put in KERNEL_ROOT_DIR.
-
-Furthermore, prerequisites may not be the same on all the applications.
-
-A SALOME Session can run on a several computers.
-
-Binary modules and prerequisites are installed on the different computers.
-There is no need to have all the modules on each computer (the minimum is
-KERNEL).
-
-There is no need of standardization or centralised information on the details
-of configuration on each computer (PATH, LD_LIBRARY_PATH, environment
-variables) provided the application modules are version - compatible. Details
-of configuration stay private to the computer, and are held by scripts on each
-computer.
-
-There is no hierarchy between the computers (for example only one master
-computer used to launch application).
-
-The SALOME user has an account on all the computers. Access between
-account@computer is via rsh or ssh and must be configured for use without
-password (key exchange for ssh). Account may be different on each
-computer.
-
-Application Directory
----------------------
-
-Two ways for creation of an application directory
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-First way - references to different module directories
-''''''''''''''''''''''''''''''''''''''''''''''''''''''
-
-The script createAppli.sh in ${KERNEL_ROOT_DIR}/bin/salome creates an
-application directory with the given path in parameter. ${APPLI} is a path
-relative to ${HOME}.
-
-The directory is only a skeleton, the user has to edit several files to
-configure his own application. These files are described after, the list is:
-
-- env.d/atFirst.sh
-- env.d/envProducts.sh
-- env.d/envSalome.sh
-- CatalogResources.xml
-- SalomeApp.xml
-
-Second and easiest way - one single virtual install directory
-'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
-
-The user must create a SALOME application configuration file by modifying a
-copy of ${KERNEL_ROOT_DIR}/bin/salome/config_appli.xml.
-The file describes the list of SALOME modules used in the application, with
-their respective installation path. The configuration file also defines the
-path of an existing script which sets the SALOME prerequisites,
-and optionnaly, the path of samples directory (SAMPLES_SRC).
-The following command::
-
- python <KERNEL_ROOT_DIR>/bin/salome/appli_gen.py --prefix=<install directory> --config=<configuration file>
-
-creates a virtual installation of SALOME in the application directory ${APPLI}
-(bin, lib, doc, share...), with, for each file (executable, script, data,
-library, resources...), symbolic links to the actual file.
-
-Providing an existing an existing script for SALOME prerequisites (the same one
-used for modules compilation, or given with the modules installation), the
-installation works without further modification for a single computer (unless
-some modules needs a special environment not defined in the above script).
-For a distributed application (several computers), one must copy and adapt
-CatalogResources.xml from ${KERNEL_ROOT_DIR}/bin/salome/appliskel (see below).
-
-General rules
--------------
-
-Directory ${APPLI} must be created on each computer of the application.
-The easiest way is to use the same relative path (to ${HOME}) on each computer.
-(Sometimes it is not possible to use the same path everywhere, for instance
-when ${HOME} is shared with NFS, so it is possible to define different path
-following the computers).
-
-The ${APPLI} directory contains scripts for environment and runs. Environment
-scripts must be configured (by the user) on each computer. All the environment
-scripts are in the ${APPLI}/env.d directory.
-
-The script ${APPLI}/envd sources **all** the files (\*.sh) in ${APPLI}/env.d
-in alphanumeric order (after edition, think to remove backup files). the envd
-script is used by run scripts.
-
-
-env.d scripts
-~~~~~~~~~~~~~
-With the first way of installation, each user **must define** his own
-configuration for these scripts, following the above rules.
-With the virtual installation (second way, above), env.d
-scripts are built automatically.
-
- **The following is only an example proposed by createAppli.sh, (first way of installation) not working as it is**.
-
-atFirst.sh
- Sets the computer configuration not directly related to SALOME,
- like useful tools, default PATH.
-
-envProducts.sh
- Sets the SALOME prerequisites.
-
-envSALOME.sh
- Sets all the MODULE_ROOT_DIR that can be used in the SALOME application.
-
- SalomeAppConfig is also defined by::
-
- export SalomeAppConfig=${HOME}/${APPLI}
-
- where SalomeAppConfig designates the directory containing SalomeApp.xml.
- Note that ${APPLI} is already defined by the calling scripts when
- env.d/envSalome.sh is sourced.
-
-User run scripts
-~~~~~~~~~~~~~~~~
-
-The SALOME user can use 4 scripts:
-
-runAppli
- Launches a SALOME Session
- (similar to ${KERNEL_ROOT_DIR}/bin/salome/runSalome but with a different
- name to avoid confusions).
-
-runSession
- Launches a shell script in the SALOME application environment, with access
- to the current (last launched) SALOME session (naming service), if any.
- Without arguments, the script is interactive. With arguments, the script
- executes the command in the SALOME application environment.
-
-runConsole
- Gives a python console connected to the current SALOME Session.
- It is also possible to use runSession, then python.
-
-runTests
- Similar to runSession, used for unit testing. runSession tries to use an
- already existing naming service definition from a running session (hostname
- and port number), runTests defines a new configuration for naming service
- (new port number).
-
-SALOME internal run scripts
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-envd
- Sets SALOME application environment, envd is sourced by other scripts.
-
-For remote calls, SALOME uses one script.
-
-runRemote.sh
- This script is mainly used to launch containers. The first 2 arguments
- define the hostname and port userd for naming service, the remaining
- arguments define the command to execute.
-
-Other configuration files
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-SalomeApp.xml
- This file is similar to the default given
- in ${GUI_ROOT_DIR}/share/salome/resources/gui
-
-
-CatalogRessources.xml
- This files describes all the computers the application can use. The given
- example is minimal and suppose ${APPLI} is the same relative path
- to ${HOME}, on all the computers. A different directory can be set on a
- particular computer with a line::
-
- appliPath="my/specific/path/on/this/computer"
-
-
-Examples of use
----------------
-
-Launch a SALOME session with a GUI interface
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Launch is done with a command like::
-
- ./runAppli --logger
-
-The --logger option means here : collect all the traces from the all the
-distributed process, via CORBA, in a single file : logger.log.
-
-There are a lot of options, a complete list is given by::
-
- ./runAppli --help
-
-Note that, without argument, runAppli is a non interactive Python application,
-and, with arguments, runAppli is an interactive Python interpreter.
-
-Several options are already defined by default in SalomeApp.xml files. Optional
-arguments given in the command override the SalomeApp.xml configuration.
-
-Several sessions can run simultaneously, each session use a different port for
-CORBA naming service, so the sessions are totally separated from each other.
-
-When the GUI is closed, the different SALOME servers are still running.
-
-Close a SALOME session, kill all the servers
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Inside the interactive python interpreter you get when you use runAppli
-with arguments, you can kill all the servers of your session with::
-
- >>> killLocalPort()
-
-or the servers of all the sessions with::
-
- >>> killAllPorts()
-
-If you have no active Python interpreter connected to your session, you can
-kill all the SALOME servers of **all the sessions** on a given computer::
-
- ./runSession killSalome.py
-
-Remember! it's the same idea in *Windows (R) operating system* [#]_ :
-use the start menu to stop...
-
-When you use only one session at a time, you don't need more.
-
-To kill a given session (when several session are running), one needs
-the naming service port number::
-
- ./runSession killSalomeWithPort 2810
-
-Note that the port number of the last launched session can be found on Linux,
-in the prompt, within a runSession shell (see below).
-
-It is also possible to get the Naming Service host and port number of
-the last launched session with::
-
- ./runSession NSparam.py
-
-.. [#] Microsoft and Windows are either registered trademarks or trademarks of
- Microsoft Corporation in the United States and/or other countries.
-
-Launch a SALOME session without GUI interface
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This is used to launch a SALOME Python script without GUI
-(no GUI server = SALOME_session_server)
-
-Example of script (test_session_geom.py)::
-
- import salome_session
- salome_session.startSession(modules=["GEOM"])
- import GEOM_usinggeom
- raw_input("Press a key and the servers will be killed ...")
-
-This script is run in a non interactive way with::
-
- ./runSession python test_session_geom.py
-
-All the process are automatically killed when Python is closed
-(with salome_session delete).
-
-Add an external Python interpretor to a running session
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-It's often easier to develop and try Python scripts outside the GUI embedded
-Python interpreter. Imagine, for instance, you are writing a script involving
-geometry and mesh modules.
-first, launch a SALOME session with gui, then, on another terminal::
-
- ./runSession
- python
-
-Import salome module. salome_init() without arguments creates a new study
-in the running session (note: salome_init(n) attachs to a running session whose
-studyId is n)::
-
- import salome
- salome.salome_init()
-
-An example of script given with SMESH::
-
- import ex01_cube2build
-
-It is possible to connect the GUI interface to the study created in the above
-script with the file/connect menu, then browse study and display objects.
-Further modifications on study can be done either with GUI or external script
-(use refresh popup in GUI object browser to see study modifications generated
-by the external script). **AVOID modifications with GUI when a Python script
-is running**. Not all the modules are protected against concurrent actions...
-
-
-Different uses of the runSession shell interpreter
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-runSession invoked without arguments gives an interactive shell with the full
-environment of SALOME (PATH, LD_LIBRARY_PATH, PYTHONPATH, other variables).
-If there are running sessions of the same SALOME application, runSession
-connects to the last launched session (i.e. gets the naming service references
-of the session: hostname and port)
-
-On Linux, the shell prompt (bash) gives information on naming service
-references, hostname and port::
-
- [NS=cli76cc:2811]prascle@cli76cc:~/SALOME2/Run/Virtual$
-
-If there is no running session, prompt looks like::
-
- [NS=:]prascle@cli76cc:~/SALOME2/Run/Virtual$
-
-runSession is useful to launch any script or program which needs the complete
-SALOME environment, with or without a session already running.
-For instance, to launch the ddd debugger interface on the gui server, first
-launch a SALOME session with gui, then, on another terminal::
-
- ./runSession ddd
-
-Then attach to the running SALOME_Session_Server process.
-
-
--------------------------------------------------------------------------------
-
-+----------------------------------+------------------------------------------+
-| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ |
-+----------------------------------+------------------------------------------+
-
-.. _`General KERNEL documentation`: ./index.html
-.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html
+++ /dev/null
-=================================================================
-Source code structuration and Unit Tests
-=================================================================
-
-*html version of this document is produced with docutils*::
-
- rst2html < doc.txt > doc.html
-
-*This document corresponds to SALOME2 3.2.0*
-
-.. contents::
-.. sectnum::
-
-+-------------------------------------------+
-| **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
-+-------------------------------------------+
-
--------------------------------------------------------------------------------
-
-You will find here general information on code directories structure,
-unit tests associated to the different kind of classes, and how to run
-the unit tests.
-
-SALOME KERNEL source code structuration
-=======================================
-
-General structure of KERNEL_SRC
--------------------------------
-
-KERNEL_SRC
- Some README files and configuration tools for build
-
-KERNEL_SRC/adm_local
- Part of the configuration files, other modules have a directory with the
- same name. Not used in KERNEL.
-
-KERNEL_SRC/bin
- Python and shell scripts used at run time.
- Kit to install a SALOME Application.
-
-KERNEL_SRC/doc
- Kit for KERNEL end user documentation production:
- public interfaces, Python, CORBA.
- Integrator and Developper documentation.
-
-KERNEL_SRC/idl
- All CORBA interfaces from KERNEL are regrouped here.
-
-KERNEL_SRC/resources
- Configuration files for servers (examples).
- Interfaces definitions for KERNEL test components.
-
-KERNEL_SRC/salome_adm
- Configuration files used by autotools (M4 macros & co.)
-
-KERNEL_SRC/src
- The source code (C++ and Python)
-
-
-Directory src: C++ and Python source code
------------------------------------------
-
-Basic services non related to CORBA
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Basics
- A set of general purpose C++ services, not related to CORBA.
- Some general purpose services that are in Utils directory (CORBA related),
- are progressivley moved here, as they are not related to CORBA.
-
-
-SALOMELocalTrace
- A multithread trace system that allows message tracing on standard error
- or a file.
-
-CASCatch
- Exceptions and signal handler.
-
-HDFPersist
- A C++ interface to HDF.
-
-Basic CORBA services
-~~~~~~~~~~~~~~~~~~~~
-
-Logger
- A CORBA server that collects the trace messages from differents CORBA
- process.
-
-SALOMETraceCollector
- A multithread trace system derived from SALOMELocalTrace, that sends messages
- to Logger server via CORBA.
-
-Utils
- A set of general purpose services related to CORBA, such as basic CORBA
- exception system. See also Basics directory above.
-
-NamingService
- C++ and Python interfaces to name, store and retrieve CORBA objects
-
-GenericObj
- A generic CORBA interface for CORBA objects, to count distributed references,
- and to allow destruction by client.
-
-Miscellaneous CORBA servers
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Registry
- Implements SALOME_registry.idl.
- Provides a CORBA server library and a separate server program.
-
-ModuleCatalog
- Implements SALOME_moduleCatalog.idl.
- Provide a CORBA server library and separate server and client programs.
-
-ModuleGenerator
- Tool to generate a module catalog from CORBA idl
-
-ResourcesManager
- library included in container server
-
-Notification
- library included in differents servers (container)
-
-NOTIFICATION_SWIG
-
-
-CORBA Containers for SALOME Modules
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Container
-
-TestContainer
-
-LifeCycleCORBA
-
-LifeCycleCORBA_SWIG
-
-STUDY server and related interfaces and tools
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-SALOMEDSClient
-
-TOOLSDS
-
-SALOMEDSImpl
-
-SALOMEDS
-
-Python interface to SALOME
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-KERNEL_PY
-
-Efficient CORBA transfer services
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Communication
-
-Communication_SWIG
-
-A Parallel container with MPI
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-MPIContainer
-
-TestMPIContainer
-
-Batch interface library
-~~~~~~~~~~~~~~~~~~~~~~~
-
-Batch
-
-Batch_SWIG
-
-Unit tests
-~~~~~~~~~~
-
-UnitTests
-
-
-Tools and principles used for Unit testing
-==========================================
-
-**TO BE COMPLETED**
-
-Unit Testing rely on cppunit package for C++ testing, and on unittest module
-for Python. See these products for general principles of unit testing.
-
-The cppunit package is optional. When the prerequisite is detected, the unit
-tests are compiled.
-
-Unit Tests sources are in directories Test under the src/directories
-containing the classes to test.
-
-Test are ordered following the order of directories given above.
-
-Tests can be run as a whole, or for a particular directory. In this case, only
-a partial test is run (the classes to test, and the classes used, i.e. the
-preceding test directories).
-
-
-Today, only some tests are written as an example. There are not yet python
-scripts in KERNEL_SRC, but it's a matter of days, there are working scripts
-to test LifeCycleCORBA_SWIG interface.
-
-
-
-
-
--------------------------------------------------------------------------------
-
-+----------------------------------+------------------------------------------+
-| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ |
-+----------------------------------+------------------------------------------+
-
-.. _`General KERNEL documentation`: ./index.html
-.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html
--- /dev/null
+# -*- coding: iso-8859-1 -*-
+# Copyright (C) 2007-2010 CEA/DEN, EDF R&D, OPEN CASCADE
+#
+# Copyright (C) 2003-2007 OPEN CASCADE, EADS/CCR, LIP6, CEA/DEN,
+# CEDRAT, EDF R&D, LEG, PRINCIPIA R&D, BUREAU VERITAS
+#
+# This library is free software; you can redistribute it and/or
+# modify it under the terms of the GNU Lesser General Public
+# License as published by the Free Software Foundation; either
+# version 2.1 of the License.
+#
+# This library is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# Lesser General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public
+# License along with this library; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+#
+# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
+
+include $(top_srcdir)/salome_adm/unix/make_common_starter.am
+
+pydocdir = $(docdir)/tui/KERNEL/docutils
+
+.PHONY : latex
+
+if SPHINX_IS_OK
+
+pydoc_DATA=html/index.html
+html/index.html:$(RSTFILES)
+ make htm
+
+endif
+
+EXTRA_DIST= html
+
+SPHINXOPTS =
+SOURCEDIR = $(srcdir)
+SPHINXBUILD = sphinx-build
+PAPEROPT_a4 = -D latex_paper_size=a4
+ALLSPHINXOPTS = -d doctrees $(PAPEROPT_a4) $(SPHINXOPTS) $(SOURCEDIR)
+
+SPHINX_PYTHONPATH = $(prefix)/lib/python$(PYTHON_VERSION)/site-packages/salome:$(KERNEL_ROOT_DIR)/bin/salome:$(OMNIORB_ROOT)/lib/python$(PYTHON_VERSION)/site-packages
+
+SPHINX_LD_LIBRARY_PATH = $(OMNIORB_ROOT)/lib
+
+htm:
+ mkdir -p html doctrees
+ PYTHONPATH=$(SPHINX_PYTHONPATH):${PYTHONPATH}; \
+ LD_LIBRARY_PATH=$(SPHINX_LD_LIBRARY_PATH):${LD_LIBRARY_PATH}; \
+ $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) html
+ @echo
+ @echo "Build finished. The HTML pages are in html."
+
+latex:
+ mkdir -p latex doctrees
+ PYTHONPATH=$(SPHINX_PYTHONPATH):${PYTHONPATH}; \
+ LD_LIBRARY_PATH=$(SPHINX_LD_LIBRARY_PATH):${LD_LIBRARY_PATH}; \
+ $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) latex
+ @echo
+ @echo "Build finished; the LaTeX files are in latex."
+ @echo "Run \`make all-pdf' or \`make all-ps' in that directory to" \
+ "run these through (pdf)latex."
+
+html:
+ mkdir -p $@
+
+RSTFILES= \
+ index.rst \
+ overview.rst \
+ docapi.rst \
+ salomepypkg.rst
+
+EXTRA_DIST+= $(RSTFILES)
+
+EXTRA_DIST+= \
+ conf.py
+
+install-data-local:
+ $(INSTALL) -d $(pydocdir)
+ if test -d "html"; then b=; else b="$(srcdir)/"; fi; \
+ cp -rf $$b"html"/* $(pydocdir) ; \
+ if test -f $$b"latex"/kernelpy.pdf; then cp -f $$b"latex"/kernelpy.pdf $(pydocdir) ; fi;
+
+uninstall-local:
+ chmod -R +w $(pydocdir)
+ rm -rf $(pydocdir)/*
+
+clean-local:
+ -rm -rf html latex doctrees
+ if test -d "html"; then rm -rf html ; fi
--- /dev/null
+=================================================================
+Installation instructions, up to date for 3.0 version
+=================================================================
+
+*html version of this document is produced with docutils*::
+
+ rst2html < doc.txt > doc.html
+
+*This document corresponds to SALOME2 2.2.9.*
+*IT IS NOT UP TO DATE with 3.2.0*
+
+.. contents::
+.. sectnum::
+
++-------------------------------------------+
+| **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
++-------------------------------------------+
+
+-------------------------------------------------------------------------------
+
+You'll find here generic instructions for installing the SALOME2 platform.
+
+Summary
+-------
+
+`1. Quick Overview`_
+
+`2. System configuration`_
+
+`3. Third-party dependencies`_
+
+`4. Preparing the shell environment`_
+
+`5. Installing the KERNEL component`_
+
+`6. Installing the SALOME components`_
+
+`7. Runtime`_
+
+`8. Suggestions and advices`_
+
+
+1. Quick Overview
+-----------------
+
+First of all, you have to check (or install if needed) the dependant
+software programs on your system. These programs are:
+
+- common development tools as gcc, automake, autoconf and libtools.
+- third party softwares used in SALOME building or runtime process
+ (python, OCC, VTK, ...)
+
+Further details can be found in sections [2] and [3].
+
+If the dependencies are installed on your system, then you have to set
+your shell environment to get access to the software components
+(cf. [4]. "Preparing the shell environment").
+
+The next step is to install the KERNEL (cf. [5] "Installing KERNEL"):
+
+::
+
+$ mkdir <kernel_build>
+$ mkdir <kernel_install>
+$ cd <kernel_src>
+$ ./build_configure
+$ cd <kernel_build>
+$ <kernel_src>/configure --prefix=<kernel_install>
+$ make
+$ make install
+
+Then, the SALOME components GEOM, MED, VISU, ... can be installed
+with a similar procedure (cf. [6]).
+
+Eventually, the platform can be run by executing the shell script
+runSalome (cf. [7]). Here, somme additionnal variables have to be set
+to describe the SALOME runtime configuration (<COMPONENT>_ROOT_DIR,
+OMNIORB_CONFIG)
+
+The following provides you with specific instructions for each step.
+
+
+2. System configuration
+-----------------------
+
+SALOME is compiled and tested on differents platforms with native packages:
+- Debian sarge
+- Mandrake 10.1
+- ...
+
+If you have another platform, we suggest the following configuration
+for building process:
+
+- gcc-3.3.x or 3.4.x
+- automake-1.7 or more (only aclocal is used)
+- autoconf-2.59
+- libtool-1.5.6
+
+remarks:
+
+- This is the minimum level of automake, autoconf and libtool, if you need
+ to compile all the third party softwares (included OpenCascade 5.2.x).
+
+3. Third-party dependencies
+---------------------------
+
+The SALOME platform relies on a set of third-party softwares. The
+current version depends on the following list
+(versions given here are from Debian Sarge, except OpenCascade, VTK and MED,
+which are not Debian packages):
+
+CAS-5.2.4 OpenCascade (try binaries,a source patch is needed)
+VTK-4.2.6 VTK 3D-viewer
+PyQt-3.13 Python-Qt Wrapper
+Python-2.3.5 Python interpreter
+SWIG-1.3.24 SWIG library
+boost-1_32_0 C++ library (only include templates are used)
+hdf5-1.6.2 Files Database library
+med-2.2.2 MED Data Format support for file records
+omniORB-4.0.5 ORB used in SALOME
+qt-x11-free-3.3.3 Qt library
+qwt-4.2 Graph components for Qt
+sip4-4.1.1 langage binding software
+
+And, in order to build the documentation:
+
+doxygen-1.4.2
+graphviz-2.2.1
+
+
+Additionnal software may be installed for optional features:
+
+netgen4.3 + patch
+tix8.1.4
+openpbs-2.3.16
+lsf-???
+
+
+
+3.1 To Do
+~~~~~~~~~
+- Instructions for installing these software programs can be found in a
+ special note doc/configuration_examples/install-prerequis.
+- Installation shell scripts are also provided.
+ These scripts have to be adapted to your own configuration.
+
+- See doc/configuration_examples/*
+
+In the following, we assume that all the third-party softwares are
+installed in the same root directory, named <salomeroot>/prerequis.
+Then, your file system should probably look like::
+
+ <salomeroot>/prerequis/Python-2.2.2
+ <salomeroot>/prerequis/omniORB-3.0.5
+ <salomeroot>/prerequis/qt-x11-free-3.0.5
+ ...
+
+
+4. Preparing the shell environment
+----------------------------------
+
+Some variables have to be set to get acces to third-party software
+components (include files, executable, library, ...) during building
+process and runtime.
+
+The shell file prerequis.sh, embedded in the KERNEL source package,
+provides a template for setting those variables. In this example, all the
+softwares are supposed to be installed in the same root directory,
+named here INSTALLROOT.
+
+Copy the prerequis.sh in a working directory and adjust the settings
+to your own configuration. To get the shell prepared, just
+execute the following command in the building shell:
+
+$ source prerequis.sh
+
+(we assume here a ksh or bash mode)
+
+
+5. Installing the KERNEL component
+----------------------------------
+
+We use here the notation <kernel_src> to specify the source directory
+of the KERNEL component. The shell environment is supposed to have
+been set (cf. 4).
+
+Installing the KERNEL from a source package needs three directories:
+
+- the source directory, denoted here by <kernel_src>.
+
+- the build directory, denoted by <kernel_build> in the following. This
+ directory can't be the same directory as <kernel_src>.
+
+- the install directory, denoted by <kernel_install> in the following. This
+ directory can't be the same directory as <kernel_src> or
+ <kernel_build>.
+
+The installing process is:
+
+STEP 1:
+ preparing directories
+
+ create the <kernel_build> and the <kernel_install> directories::
+
+ $ mkdir <kernel_build>
+ $ mkdir <kernel_install>
+
+STEP 2:
+ build configure script
+
+ go to <kernel_src> directory and generate the "configure" script::
+
+ $ cd <kernel_src>
+ $ ./build_configure
+
+ If it doesn't work, check your system automake tools as specified in
+ section [2].
+
+STEP 3:
+ configure the building process
+ go to the build directory and execute the configuration process::
+
+ $ cd <kernel_build>
+ $ <kernel_src>/configure --prefix=<kernel_install>
+
+ Note that <kernel_install> must be an absolute path.
+
+ When the configure process is complete, check the status of
+ third-party softwares detection. You should have a status like::
+
+ ---------------------------------------------
+ Summary
+ ---------------------------------------------
+ Configure
+ cc : yes
+ boost : yes
+ lex_yacc : yes
+ python : yes
+ swig : yes
+ threads : yes
+ OpenGL : yes
+ qt : yes
+ vtk : yes
+ hdf5 : yes
+ med2 : yes
+ omniORB : yes
+ occ : yes
+ sip : yes
+ pyqt : yes
+ qwt : yes
+ doxygen : yes
+ graphviz : no
+ openpbs : no
+ lsf : no
+ Default ORB : omniORB
+ ----------------------------------------------
+
+If a software get a status "no", then it's not "seen" in the system:
+
+- the software is not installed, or
+- the shell environment is not set correctly.
+
+In this example, the software programs graphviz, openpbs and lsf are not
+installed (optional for most usages).
+
+
+STEP 4 :
+ Building the binary files
+
+ Execute make in the <kernel_build> directory::
+
+ $ make
+
+
+STEP 5:
+ Installing binary files, scripts and documentation
+
+ Execute install target in the <kernel_build> directory::
+
+ $ make install
+
+
+6. Installing the SALOME components
+-----------------------------------
+
+TInstalling a component <COMPONENT> is done by following the same
+instructions as given for the KERNEL, replacing KERNEL by
+<COMPONENT> (build_configure, configure, make, make install).
+
+You just have to be aware of the dependencies between components:
+
+- MED depends on KERNEL
+- GEOM depends on KERNEL
+- SMESH depends on KERNEL, MED, GEOM
+- VISU depends on KERNEL, MED
+- SUPERV depends on KERNEL
+
+For example, installing the component SMESH needs the previous
+installation of the KERNEL component, and then the GEOM and MED components.
+
+The building process uses the variables <COMPONENT>_ROOT_DIR to
+localize the dependant components. The variables must be set to the
+install path directory of the components <COMPONENT> (ex:
+KERNEL_ROOT_DIR=<kernel_install>).
+
+In the above example, the three variables KERNEL_ROOT_DIR,
+GEOM_ROOT_DIR and MED_ROOT_DIR have to be set before configuring the
+building process of the SMESH component (STEP 3).
+
+
+7. Runtime
+----------
+
+See SALOME_Application_ to define your own configuration of SALOME and run it
+on one or several computers. This is the recommended way of configuration.
+
+.. _SALOME_Application: ./SALOME_Application.html
+
+The following explains the general principles.
+
+To run the SALOME platform, the procedure is:
+
+- set the shell environment to get acces to third-party softwares::
+
+ $ source prerequis.sh
+
+- define the SALOME configuration by setting the whole set of
+ variables <COMPONENT>_ROOT_DIR. Here, you just have to set the
+ kernel and the components you need::
+
+ $ export KERNEL_ROOT_DIR=<kernel_install>
+ $ export MED_ROOT_DIR=<med_install>
+ $ ...
+
+- define the CORBA configuration file by setting the variable
+ OMNIORB_CONFIG. This variable must be set to a writable file
+ path. The file may be arbitrary chosen and doesn't need to exist
+ before running. We suggest::
+
+ $ export OMNIORB_CONFIG=$HOME/.omniORB.cfg
+
+- run the SALOME platform by executing the script runSalome::
+
+ $KERNEL_ROOT_DIR/bin/salome/runSalome
+
+
+8. Suggestions and advices
+--------------------------
+
+For convenience or customization, we suggest the following organisation:
+
+- chose and create a root directory for the SALOME platform, say
+ <salomeroot>.
+
+- install the third-party softwares in a sub-directory "prerequis"
+
+- install the SALOME components in a sub-directory "SALOME2"
+
+- make personnal copies of the files prerequis.sh and runSalome in
+ <salomeroot>::
+
+ $ cp <kernel_src>/prerequis.sh <rundir>/.
+ $ cp <kernel_install>/bin/salome/runSalome <rundir>/.
+
+ Edit the file prerequis.sh and adjust it to your own configuration.
+
+- define the SALOME2 configuration
+
+ This step consists in setting the KERNEL_ROOT_DIR, the whole set of
+ variables <COMPONENT>_ROOT_DIR you need, and the OMNIORB_CONFIG
+ variable.
+
+ We suggest to create a shell file envSalome.sh containing those
+ settings. Then the configuration consists in loading envSalome.sh in
+ the runtime shell::
+
+ $ source envSalome.sh
+
+- When installed with this file organisation, running SALOME is done
+ with the following shell commands::
+
+ $ source <salomeroot>/prerequis.sh
+ $ source <salomeroot>/envSalome.sh
+ $ ./runSalome
+
+
+-------------------------------------------------------------------------------
+
++----------------------------------+------------------------------------------+
+| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ |
++----------------------------------+------------------------------------------+
+
+.. _`General KERNEL documentation`: ./index.html
+.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html
--- /dev/null
+=================================================================
+KERNEL Services for end user (Python interface)
+=================================================================
+
+*html version of this document is produced with docutils*::
+
+ rst2html < doc.txt > doc.html
+
+This document corresponds to SALOME2 3.2.0
+
+.. contents::
+.. sectnum::
+
++-------------------------------------------+
+| **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
++-------------------------------------------+
+
+-------------------------------------------------------------------------------
+
+In a SALOME application, distributed components, servers and clients use
+the CORBA middleware for comunication. CORBA interfaces are defined via idl
+files. All the different CORBA interfaces are available for users in Python,
+see CORBA interfaces below.
+
+For some general purpose services, CORBA interfaces have been encapsulated
+in order to provide a simple interface (encapsulation is generally done in
+C++ classes, and a Python SWIG interface is also generated from C++, to
+ensure a consistent behavior between C++ modules and Python modules or user
+script).
+
+General purpose services
+========================
+
+SALOME services access from a Python shell
+------------------------------------------
+See SALOME_Application_ for detailed instructions to launch a Python
+interpreter with full acces to the SALOME environment and services.
+
+.. _SALOME_Application: ./SALOME_Application.txt
+
+You can use the embedded Python interpreter in Grahic User Interface, or an
+external interpreter, with::
+
+ ./runSession
+ python
+
+In either cases, SALOME services access is done with::
+
+ import salome
+ salome.salome_init()
+
+In the embedded interpreter, it is already done, but there is no problem to
+do it several times, so it is preferable to add these instructions
+systematically in your scripts, to allow them to work in all configurations.
+
+Container and component instanciation
+-------------------------------------
+
+See LifeCycleCORBA_ for the C++ interface (Python interface obtained with SWIG
+is very similar).
+
+.. _LifeCycleCORBA: ./tui/KERNEL/classSALOME__LifeCycleCORBA.html
+
+
+In the following example, a test component provided in KERNEL is launched
+in the local container, "FactoryServer", created when SALOME starts::
+
+ import salome
+ salome.salome_init()
+
+ import LifeCycleCORBA
+ lcc = LifeCycleCORBA.LifeCycleCORBA()
+ obj=lcc.FindOrLoad_Component("FactoryServer","SalomeTestComponent")
+
+ import Engines
+ comp=obj._narrow(Engines.TestComponent)
+
+ comp.Coucou(1)
+
+The answer is something like::
+
+ 'TestComponent_i : L = 1'
+
+The _narrow() instruction is not always mandatory in Python, but sometimes
+useful to be sure you have got the right type of object. Here, Testcomponent_
+interface is defined in CORBA module Engines. With this example, it works also
+without the _narrow() instruction::
+
+ obj.Coucou(1)
+
+.. _Testcomponent: ./tui/KERNEL/interfaceEngines_1_1TestComponent.html
+
+
+In the next example, a component instance is created in a specific Container
+defined by it's computer hostname and it's name. Here we use the local
+computer. Note that in Utils_Identity_, getShortHostName() gives the short
+hostname of the computer, without domain suffixes, which is used in SALOME.
+The container process is created here if it does not exists, and a new
+component instance is created::
+
+ import salome
+ salome.salome_init()
+ import LifeCycleCORBA
+ lcc = LifeCycleCORBA.LifeCycleCORBA()
+
+ import Utils_Identity
+ host = Utils_Identity.getShortHostName()
+
+ import Engines
+ params={}
+ params['hostname']=host
+ params['container_name']='myContainer'
+ comp=lcc.LoadComponent(params,'SalomeTestComponent')
+ comp.Coucou(1)
+
+.. _Utils_Identity: ./tui/KERNEL/namespaceUtils__Identity.html
+
+If you want to get a list of containers and component instances, client object
+from orbmodule_ provides a list::
+
+ import orbmodule
+ clt=orbmodule.client()
+ clt.showNS()
+
+.. _orbmodule: ./tui/KERNEL/classorbmodule_1_1client.html
+
+The list looks like::
+
+ Logger.
+ ContainerManager.object
+ Containers.dir
+ cli70ac.dir
+ FactoryServerPy.object
+ SuperVisionContainer.object
+ FactoryServer.object
+ FactoryServer.dir
+ SalomeTestComponent_inst_1.object
+ myContainer.object
+ myContainer.dir
+ SalomeTestComponent_inst_1.object
+ SalomeTestComponent_inst_2.object
+ Registry.object
+ Kernel.dir
+ ModulCatalog.object
+ Session.object
+ Study.dir
+ Study2.object
+ extStudy_1.object
+ extStudy_2.object
+ extStudy_3.object
+ myStudyManager.object
+ SalomeAppEngine.object
+
+
+File transfer service
+---------------------
+
+See FileTransferCORBA_ for the C++ interface (Python interface obtained with
+SWIG is very similar).
+
+.. _FileTransferCORBA: ./tui/KERNEL/classSALOME__FileTransferCORBA.html
+
+The following example shows how to tranfer a file from a remote host to the
+client computer. Remote hostname is 'cli76cc', we would like to copy
+'tkcvs_8_0_3.tar.gz' from remote to local computer. A full pathname is
+required. A container is created on remote computer if it does not exist,
+to handle the file transfer::
+
+ import salome
+ salome.salome_init()
+
+ import LifeCycleCORBA
+ remotefile="/home/prascle/tkcvs_8_0_3.tar.gz"
+ aFileTransfer=LifeCycleCORBA.SALOME_FileTransferCORBA('cli76cc',remotefile)
+ localFile=aFileTransfer.getLocalFile()
+
+
+CORBA Naming service access
+---------------------------
+
+See SALOME_NamingService_ for the C++ interface. The Python interface
+SALOME_NamingServicePy_ is not yet derived from the C++ interface and offers
+only the most useful functions.
+
+.. _SALOME_NamingService: ./tui/KERNEL/classSALOME__NamingService.html
+.. _SALOME_NamingServicePy: ./tui/KERNEL/classSALOME__NamingServicePy_1_1SALOME__NamingServicePy__i.html
+
+Batch services
+--------------
+
+See Batch_ documentation (in french only).
+
+.. _Batch: ./Batch.html/index.html
+
+All IDL Interfaces
+==================
+
+Containers and component life cycle, File transfer service
+----------------------------------------------------------
+
++-----------------------------+-----------------------------------------------+
+| Engines_ | Engines CORBA module. |
++=============================+===============================================+
+| Component_ | Generic component interface. |
+| | All SALOME components inherit this interface |
++-----------------------------+-----------------------------------------------+
+| Container_ | Container: host for C++ and Python components |
+| | components instances |
++-----------------------------+-----------------------------------------------+
+| FileTransfer_ | Agent for file transfer created by a container|
+| | copy a local file to a distent client |
++-----------------------------+-----------------------------------------------+
+| FileRef_ | Reference to a file, used by a container for |
+| | file transfers |
++-----------------------------+-----------------------------------------------+
+| ContainerManager_ | Unique instance, in charge of container |
+| | creation on remote computers |
++-----------------------------+-----------------------------------------------+
+| MPIContainer_ | An exemple of parallel implementation for |
+| | containers and components |
++-----------------------------+-----------------------------------------------+
+| MPIObject_ | |
++-----------------------------+-----------------------------------------------+
+
+Study management
+----------------
+
++-----------------------------+-----------------------------------------------+
+| SALOMEDS_ | SALOMEDS CORBA module |
++=============================+===============================================+
+| SALOMEDSidl_ | |
++-----------------------------+-----------------------------------------------+
+| SALOMEDS_Attributes_ | |
++-----------------------------+-----------------------------------------------+
+
+High speed transfer, object life cycle, exceptions, GUI interface...
+--------------------------------------------------------------------
+
++-----------------------------+-----------------------------------------------+
+| SALOME_ | SALOME CORBA module |
++=============================+===============================================+
+| SALOME_Comm_ | |
++-----------------------------+-----------------------------------------------+
+| SALOME_GenericObj_ | |
++-----------------------------+-----------------------------------------------+
+| SALOME_Exception_ | |
++-----------------------------+-----------------------------------------------+
+| SALOME_Session_ | |
++-----------------------------+-----------------------------------------------+
+
+Miscelleanous
+-------------
++-----------------------------+-----------------------------------------------+
+| | other CORBA modules |
++=============================+===============================================+
+| SALOME_ModuleCatalog_ | |
++-----------------------------+-----------------------------------------------+
+| SALOME_RessourcesCatalog_ | |
++-----------------------------+-----------------------------------------------+
+| SALOME_Registry_ | |
++-----------------------------+-----------------------------------------------+
+| Logger_ | |
++-----------------------------+-----------------------------------------------+
+
+**Other idl for test purposes**
+nstest.idl
+SALOME_TestComponent.idl
+SALOME_TestModuleCatalog.idl
+SALOME_TestMPIComponent.idl
+TestNotif.idl
+
+.. _Engines: ./tui/KERNEL/namespaceEngines.html
+.. _Component: ./tui/KERNEL/interfaceEngines_1_1Component.html
+.. _Container: ./tui/KERNEL/interfaceEngines_1_1Container.html
+.. _fileTransfer: ./tui/KERNEL/interfaceEngines_1_1fileTransfer.html
+.. _fileRef: ./tui/KERNEL/interfaceEngines_1_1fileRef.html
+.. _ContainerManager: ./tui/KERNEL/interfaceEngines_1_1ContainerManager.html
+.. _MPIContainer: ./tui/KERNEL/interfaceEngines_1_1MPIContainer.html
+.. _MPIObject: ./tui/KERNEL/interfaceEngines_1_1MPIObject.html
+.. _SALOME: ./tui/KERNEL/namespaceSALOME.html
+.. _SALOMEDS: ./tui/KERNEL/namespaceSALOMEDS.html
+.. _SALOME_Component: ./tui/KERNEL/SALOME__Component_8idl.html
+.. _SALOME_ContainerManager: ./tui/KERNEL/SALOME__ContainerManager_8idl.html
+.. _SALOMEDSidl: ./tui/KERNEL/SALOMEDS_8idl.html
+.. _SALOMEDS_Attributes: ./tui/KERNEL/SALOMEDS__Attributes_8idl.html
+.. _SALOME_ModuleCatalog: ./tui/KERNEL/SALOME__ModuleCatalog_8idl.html
+.. _SALOME_RessourcesCatalog: ./tui/KERNEL/SALOME__RessourcesCatalog_8idl.html
+.. _SALOME_Registry: ./tui/KERNEL/SALOME__Registry_8idl.html
+.. _Logger: ./tui/KERNEL/Logger_8idl.html
+.. _SALOME_Comm: ./tui/KERNEL/SALOME__Comm_8idl.html
+.. _SALOME_GenericObj: ./tui/KERNEL/SALOME__GenericObj_8idl.html
+.. _SALOME_Exception: ./tui/KERNEL/SALOME__Exception_8idl.html
+.. _SALOME_Session: ./tui/KERNEL/SALOME__Session_8idl.html
+.. _SALOME_MPIContainer: ./tui/KERNEL/SALOME__MPIContainer_8idl.html
+.. _SALOME_MPIObject: ./tui/KERNEL/SALOME__MPIObject_8idl.html
+
+
+-------------------------------------------------------------------------------
+
++----------------------------------+------------------------------------------+
+| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ |
++----------------------------------+------------------------------------------+
+
+.. _`General KERNEL documentation`: ./index.html
+.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html
--- /dev/null
+======================================================================
+SALOME Application Concept. Configuration for one or more computers
+======================================================================
+
+*html version of this document is produced with docutils*::
+
+ rst2html doc.txt > doc.html
+
+This document corresponds to SALOME2 3.2.0
+
+.. contents::
+.. sectnum::
+
++-------------------------------------------+
+| **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
++-------------------------------------------+
+
+-------------------------------------------------------------------------------
+
+The following explains how to configure your own application with your list of
+modules, how to define and run this application on one or more computers.
+
+General principles
+------------------
+
+A SALOME application is defined by a set of modules (GEOM, SMESH, ASTER...).
+
+A SALOME User can define several SALOME Applications. These applications are
+runnable from the same user account. These applications may share the same
+KERNEL and modules. Thus, the application configuration is independant of
+KERNEL and must not be put in KERNEL_ROOT_DIR.
+
+Furthermore, prerequisites may not be the same on all the applications.
+
+A SALOME Session can run on a several computers.
+
+Binary modules and prerequisites are installed on the different computers.
+There is no need to have all the modules on each computer (the minimum is
+KERNEL).
+
+There is no need of standardization or centralised information on the details
+of configuration on each computer (PATH, LD_LIBRARY_PATH, environment
+variables) provided the application modules are version - compatible. Details
+of configuration stay private to the computer, and are held by scripts on each
+computer.
+
+There is no hierarchy between the computers (for example only one master
+computer used to launch application).
+
+The SALOME user has an account on all the computers. Access between
+account@computer is via rsh or ssh and must be configured for use without
+password (key exchange for ssh). Account may be different on each
+computer.
+
+Application Directory
+---------------------
+
+Two ways for creation of an application directory
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+First way - references to different module directories
+''''''''''''''''''''''''''''''''''''''''''''''''''''''
+
+The script createAppli.sh in ${KERNEL_ROOT_DIR}/bin/salome creates an
+application directory with the given path in parameter. ${APPLI} is a path
+relative to ${HOME}.
+
+The directory is only a skeleton, the user has to edit several files to
+configure his own application. These files are described after, the list is:
+
+- env.d/atFirst.sh
+- env.d/envProducts.sh
+- env.d/envSalome.sh
+- CatalogResources.xml
+- SalomeApp.xml
+
+Second and easiest way - one single virtual install directory
+'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
+
+The user must create a SALOME application configuration file by modifying a
+copy of ${KERNEL_ROOT_DIR}/bin/salome/config_appli.xml.
+The file describes the list of SALOME modules used in the application, with
+their respective installation path. The configuration file also defines the
+path of an existing script which sets the SALOME prerequisites,
+and optionnaly, the path of samples directory (SAMPLES_SRC).
+The following command::
+
+ python <KERNEL_ROOT_DIR>/bin/salome/appli_gen.py --prefix=<install directory> --config=<configuration file>
+
+creates a virtual installation of SALOME in the application directory ${APPLI}
+(bin, lib, doc, share...), with, for each file (executable, script, data,
+library, resources...), symbolic links to the actual file.
+
+Providing an existing an existing script for SALOME prerequisites (the same one
+used for modules compilation, or given with the modules installation), the
+installation works without further modification for a single computer (unless
+some modules needs a special environment not defined in the above script).
+For a distributed application (several computers), one must copy and adapt
+CatalogResources.xml from ${KERNEL_ROOT_DIR}/bin/salome/appliskel (see below).
+
+General rules
+-------------
+
+Directory ${APPLI} must be created on each computer of the application.
+The easiest way is to use the same relative path (to ${HOME}) on each computer.
+(Sometimes it is not possible to use the same path everywhere, for instance
+when ${HOME} is shared with NFS, so it is possible to define different path
+following the computers).
+
+The ${APPLI} directory contains scripts for environment and runs. Environment
+scripts must be configured (by the user) on each computer. All the environment
+scripts are in the ${APPLI}/env.d directory.
+
+The script ${APPLI}/envd sources **all** the files (\*.sh) in ${APPLI}/env.d
+in alphanumeric order (after edition, think to remove backup files). the envd
+script is used by run scripts.
+
+
+env.d scripts
+~~~~~~~~~~~~~
+With the first way of installation, each user **must define** his own
+configuration for these scripts, following the above rules.
+With the virtual installation (second way, above), env.d
+scripts are built automatically.
+
+ **The following is only an example proposed by createAppli.sh, (first way of installation) not working as it is**.
+
+atFirst.sh
+ Sets the computer configuration not directly related to SALOME,
+ like useful tools, default PATH.
+
+envProducts.sh
+ Sets the SALOME prerequisites.
+
+envSALOME.sh
+ Sets all the MODULE_ROOT_DIR that can be used in the SALOME application.
+
+ SalomeAppConfig is also defined by::
+
+ export SalomeAppConfig=${HOME}/${APPLI}
+
+ where SalomeAppConfig designates the directory containing SalomeApp.xml.
+ Note that ${APPLI} is already defined by the calling scripts when
+ env.d/envSalome.sh is sourced.
+
+User run scripts
+~~~~~~~~~~~~~~~~
+
+The SALOME user can use 4 scripts:
+
+runAppli
+ Launches a SALOME Session
+ (similar to ${KERNEL_ROOT_DIR}/bin/salome/runSalome but with a different
+ name to avoid confusions).
+
+runSession
+ Launches a shell script in the SALOME application environment, with access
+ to the current (last launched) SALOME session (naming service), if any.
+ Without arguments, the script is interactive. With arguments, the script
+ executes the command in the SALOME application environment.
+
+runConsole
+ Gives a python console connected to the current SALOME Session.
+ It is also possible to use runSession, then python.
+
+runTests
+ Similar to runSession, used for unit testing. runSession tries to use an
+ already existing naming service definition from a running session (hostname
+ and port number), runTests defines a new configuration for naming service
+ (new port number).
+
+SALOME internal run scripts
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+envd
+ Sets SALOME application environment, envd is sourced by other scripts.
+
+For remote calls, SALOME uses one script.
+
+runRemote.sh
+ This script is mainly used to launch containers. The first 2 arguments
+ define the hostname and port userd for naming service, the remaining
+ arguments define the command to execute.
+
+Other configuration files
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+SalomeApp.xml
+ This file is similar to the default given
+ in ${GUI_ROOT_DIR}/share/salome/resources/gui
+
+
+CatalogRessources.xml
+ This files describes all the computers the application can use. The given
+ example is minimal and suppose ${APPLI} is the same relative path
+ to ${HOME}, on all the computers. A different directory can be set on a
+ particular computer with a line::
+
+ appliPath="my/specific/path/on/this/computer"
+
+
+Examples of use
+---------------
+
+Launch a SALOME session with a GUI interface
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Launch is done with a command like::
+
+ ./runAppli --logger
+
+The --logger option means here : collect all the traces from the all the
+distributed process, via CORBA, in a single file : logger.log.
+
+There are a lot of options, a complete list is given by::
+
+ ./runAppli --help
+
+Note that, without argument, runAppli is a non interactive Python application,
+and, with arguments, runAppli is an interactive Python interpreter.
+
+Several options are already defined by default in SalomeApp.xml files. Optional
+arguments given in the command override the SalomeApp.xml configuration.
+
+Several sessions can run simultaneously, each session use a different port for
+CORBA naming service, so the sessions are totally separated from each other.
+
+When the GUI is closed, the different SALOME servers are still running.
+
+Close a SALOME session, kill all the servers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Inside the interactive python interpreter you get when you use runAppli
+with arguments, you can kill all the servers of your session with::
+
+ >>> killLocalPort()
+
+or the servers of all the sessions with::
+
+ >>> killAllPorts()
+
+If you have no active Python interpreter connected to your session, you can
+kill all the SALOME servers of **all the sessions** on a given computer::
+
+ ./runSession killSalome.py
+
+Remember! it's the same idea in *Windows (R) operating system* [#]_ :
+use the start menu to stop...
+
+When you use only one session at a time, you don't need more.
+
+To kill a given session (when several session are running), one needs
+the naming service port number::
+
+ ./runSession killSalomeWithPort 2810
+
+Note that the port number of the last launched session can be found on Linux,
+in the prompt, within a runSession shell (see below).
+
+It is also possible to get the Naming Service host and port number of
+the last launched session with::
+
+ ./runSession NSparam.py
+
+.. [#] Microsoft and Windows are either registered trademarks or trademarks of
+ Microsoft Corporation in the United States and/or other countries.
+
+Launch a SALOME session without GUI interface
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This is used to launch a SALOME Python script without GUI
+(no GUI server = SALOME_session_server)
+
+Example of script (test_session_geom.py)::
+
+ import salome_session
+ salome_session.startSession(modules=["GEOM"])
+ import GEOM_usinggeom
+ raw_input("Press a key and the servers will be killed ...")
+
+This script is run in a non interactive way with::
+
+ ./runSession python test_session_geom.py
+
+All the process are automatically killed when Python is closed
+(with salome_session delete).
+
+Add an external Python interpretor to a running session
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It's often easier to develop and try Python scripts outside the GUI embedded
+Python interpreter. Imagine, for instance, you are writing a script involving
+geometry and mesh modules.
+first, launch a SALOME session with gui, then, on another terminal::
+
+ ./runSession
+ python
+
+Import salome module. salome_init() without arguments creates a new study
+in the running session (note: salome_init(n) attachs to a running session whose
+studyId is n)::
+
+ import salome
+ salome.salome_init()
+
+An example of script given with SMESH::
+
+ import ex01_cube2build
+
+It is possible to connect the GUI interface to the study created in the above
+script with the file/connect menu, then browse study and display objects.
+Further modifications on study can be done either with GUI or external script
+(use refresh popup in GUI object browser to see study modifications generated
+by the external script). **AVOID modifications with GUI when a Python script
+is running**. Not all the modules are protected against concurrent actions...
+
+
+Different uses of the runSession shell interpreter
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+runSession invoked without arguments gives an interactive shell with the full
+environment of SALOME (PATH, LD_LIBRARY_PATH, PYTHONPATH, other variables).
+If there are running sessions of the same SALOME application, runSession
+connects to the last launched session (i.e. gets the naming service references
+of the session: hostname and port)
+
+On Linux, the shell prompt (bash) gives information on naming service
+references, hostname and port::
+
+ [NS=cli76cc:2811]prascle@cli76cc:~/SALOME2/Run/Virtual$
+
+If there is no running session, prompt looks like::
+
+ [NS=:]prascle@cli76cc:~/SALOME2/Run/Virtual$
+
+runSession is useful to launch any script or program which needs the complete
+SALOME environment, with or without a session already running.
+For instance, to launch the ddd debugger interface on the gui server, first
+launch a SALOME session with gui, then, on another terminal::
+
+ ./runSession ddd
+
+Then attach to the running SALOME_Session_Server process.
+
+
+-------------------------------------------------------------------------------
+
++----------------------------------+------------------------------------------+
+| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ |
++----------------------------------+------------------------------------------+
+
+.. _`General KERNEL documentation`: ./index.html
+.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html
--- /dev/null
+=================================================================
+Source code structuration and Unit Tests
+=================================================================
+
+*html version of this document is produced with docutils*::
+
+ rst2html < doc.txt > doc.html
+
+*This document corresponds to SALOME2 3.2.0*
+
+.. contents::
+.. sectnum::
+
++-------------------------------------------+
+| **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
++-------------------------------------------+
+
+-------------------------------------------------------------------------------
+
+You will find here general information on code directories structure,
+unit tests associated to the different kind of classes, and how to run
+the unit tests.
+
+SALOME KERNEL source code structuration
+=======================================
+
+General structure of KERNEL_SRC
+-------------------------------
+
+KERNEL_SRC
+ Some README files and configuration tools for build
+
+KERNEL_SRC/adm_local
+ Part of the configuration files, other modules have a directory with the
+ same name. Not used in KERNEL.
+
+KERNEL_SRC/bin
+ Python and shell scripts used at run time.
+ Kit to install a SALOME Application.
+
+KERNEL_SRC/doc
+ Kit for KERNEL end user documentation production:
+ public interfaces, Python, CORBA.
+ Integrator and Developper documentation.
+
+KERNEL_SRC/idl
+ All CORBA interfaces from KERNEL are regrouped here.
+
+KERNEL_SRC/resources
+ Configuration files for servers (examples).
+ Interfaces definitions for KERNEL test components.
+
+KERNEL_SRC/salome_adm
+ Configuration files used by autotools (M4 macros & co.)
+
+KERNEL_SRC/src
+ The source code (C++ and Python)
+
+
+Directory src: C++ and Python source code
+-----------------------------------------
+
+Basic services non related to CORBA
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Basics
+ A set of general purpose C++ services, not related to CORBA.
+ Some general purpose services that are in Utils directory (CORBA related),
+ are progressivley moved here, as they are not related to CORBA.
+
+
+SALOMELocalTrace
+ A multithread trace system that allows message tracing on standard error
+ or a file.
+
+CASCatch
+ Exceptions and signal handler.
+
+HDFPersist
+ A C++ interface to HDF.
+
+Basic CORBA services
+~~~~~~~~~~~~~~~~~~~~
+
+Logger
+ A CORBA server that collects the trace messages from differents CORBA
+ process.
+
+SALOMETraceCollector
+ A multithread trace system derived from SALOMELocalTrace, that sends messages
+ to Logger server via CORBA.
+
+Utils
+ A set of general purpose services related to CORBA, such as basic CORBA
+ exception system. See also Basics directory above.
+
+NamingService
+ C++ and Python interfaces to name, store and retrieve CORBA objects
+
+GenericObj
+ A generic CORBA interface for CORBA objects, to count distributed references,
+ and to allow destruction by client.
+
+Miscellaneous CORBA servers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Registry
+ Implements SALOME_registry.idl.
+ Provides a CORBA server library and a separate server program.
+
+ModuleCatalog
+ Implements SALOME_moduleCatalog.idl.
+ Provide a CORBA server library and separate server and client programs.
+
+ModuleGenerator
+ Tool to generate a module catalog from CORBA idl
+
+ResourcesManager
+ library included in container server
+
+Notification
+ library included in differents servers (container)
+
+NOTIFICATION_SWIG
+
+
+CORBA Containers for SALOME Modules
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Container
+
+TestContainer
+
+LifeCycleCORBA
+
+LifeCycleCORBA_SWIG
+
+STUDY server and related interfaces and tools
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+SALOMEDSClient
+
+TOOLSDS
+
+SALOMEDSImpl
+
+SALOMEDS
+
+Python interface to SALOME
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+KERNEL_PY
+
+Efficient CORBA transfer services
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Communication
+
+Communication_SWIG
+
+A Parallel container with MPI
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+MPIContainer
+
+TestMPIContainer
+
+Batch interface library
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Batch
+
+Batch_SWIG
+
+Unit tests
+~~~~~~~~~~
+
+UnitTests
+
+
+Tools and principles used for Unit testing
+==========================================
+
+**TO BE COMPLETED**
+
+Unit Testing rely on cppunit package for C++ testing, and on unittest module
+for Python. See these products for general principles of unit testing.
+
+The cppunit package is optional. When the prerequisite is detected, the unit
+tests are compiled.
+
+Unit Tests sources are in directories Test under the src/directories
+containing the classes to test.
+
+Test are ordered following the order of directories given above.
+
+Tests can be run as a whole, or for a particular directory. In this case, only
+a partial test is run (the classes to test, and the classes used, i.e. the
+preceding test directories).
+
+
+Today, only some tests are written as an example. There are not yet python
+scripts in KERNEL_SRC, but it's a matter of days, there are working scripts
+to test LifeCycleCORBA_SWIG interface.
+
+
+
+
+
+-------------------------------------------------------------------------------
+
++----------------------------------+------------------------------------------+
+| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ |
++----------------------------------+------------------------------------------+
+
+.. _`General KERNEL documentation`: ./index.html
+.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html
--- /dev/null
+=================================================================
+KERNEL common Services
+=================================================================
+
+*html version of this document is produced with docutils*::
+
+ rst2html < doc.txt > doc.html
+
+*This document corresponds to SALOME2 3.2.0*
+
+.. contents::
+.. sectnum::
+
++-------------------------------------------+
+| **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
++-------------------------------------------+
+
+-------------------------------------------------------------------------------
+
+**General information, for users, integrators and developers**
+
+**Users, integrators and developers, which documentation ?**
+
+Following your kind of usage of SALOME, you will find some specific
+introductory documentation, listed below.
+
+End user
+========
+
+How to configure a SALOME application
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The end user may have to configure his own SALOME application by selection of a
+subset of availables SALOME modules. He also may want to install his
+application on several computers.
+
+See SALOME_Application_ to define your own configuration of SALOME and run it
+on one or several computers. This is the recommended way of configuration.
+
+.. _SALOME_Application: ./SALOME_Application.html
+
+
+How to launch SALOME in a SALOME application
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+See SALOME_Application_.
+
+How to use KERNEL services in Python scripts
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The SALOME KERNEL offers offers a list of services available in Python.
+
+See KERNEL_Services_.
+
+.. _KERNEL_Services: ./KERNEL_Services.html
+
+Application Integrator
+======================
+
+Applications integrators are in charge of configuration and installation of
+specific SALOME applications over a local network. Application Integrators
+built SALOME modules binaries from sources tarballs.
+
+How to install SALOME
+~~~~~~~~~~~~~~~~~~~~~
+
+See INSTALL_ for general information on required configuration and
+prerequisites, compilation procedure, setting environment principles.
+
+.. _INSTALL: ./INSTALL.html
+
+How to configure a SALOME application
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+See SALOME_Application_ to define your own configuration of SALOME and run it
+on one or several computers. This is the recommended way of configuration.
+
+.. _SALOME_Application: ./SALOME_Application.html
+
+
+Module maintainer
+=================
+
+Module maintainers are in charge of the development and debug of the SALOME
+modules. Each SALOME module is stored in a CVS base. CVS bases are organised
+in separate branches for developments and debug. All official or development
+releases are identified by a CVS tag.
+
+Source code structuration and Unit Tests
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+See UnitTests_ for general information on code directories structure,
+unit tests associated to the different kind of classes, and how to run
+the unit tests.
+
+.. _UnitTests: ./UnitTests.html
+
+Some development utilities
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+See kernel_resources_ for information on basic utilities for C++ and Python
+development, like trace and debug, exceptions, singleton.
+
+.. _kernel_resources: ./kernel_resources.html
+
+-------------------------------------------------------------------------------
+
++----------------------------------+------------------------------------------+
+| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ |
++----------------------------------+------------------------------------------+
+
+.. _`General KERNEL documentation`: ./index.html
+.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html
--- /dev/null
+======================================================================
+SALOME Kernel resources for developer
+======================================================================
+
+*html version of this document is produced with docutils*::
+
+ rst2html doc.txt > doc.html
+
+*This document corresponds to SALOME2 3.2.0*
+
+:Authors:
+ Antoine Yessayan,
+ Paul Rascle
+
+:Version: 0.3 - february 17, 2006
+
++-------------------------------------------+
+| **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
++-------------------------------------------+
+
+-------------------------------------------------------------------------------
+
+**Abstract**
+
+This document describes the development environment for
+C++ and Python. Makefiles generation and usage are
+introduced in another document: "using the SALOME
+configuration and building system environment".
+Development environment is intended here as: trace and
+debug macros usage; SALOME exceptions usage, in C++ and
+Python; user CORBA exceptions usage, in C++ and Python,
+with and without Graphical User Interface; some general
+purpose services such as singleton, used for CORBA
+connection and disconnection.
+
+.. contents::
+.. sectnum::
+
+-------------------------------------------------------------------------------
+
+Trace and debug Utilities
+=========================
+
+During the development process, an execution log is
+useful to identify problems. This log contains
+messages, variables values, source files names and line
+numbers. It is recommended to verify assertions on
+variables values and if necessary, to stop the
+execution at debug time, in order to validate all parts
+of code.
+
+Two modes: debug and release
+----------------------------
+
+The goal of debug mode is to check as many features as
+possible during the early stages of the development
+process. The purpose of the utilities provided in
+SALOME is to help the developer to add detailed traces
+and check variables values, without writing a lot of code.
+
+When the code is assumed to be valid, the release mode
+optimizes execution, in terms of speed, memory, and
+display only user level messages.
+
+But, some informations must always be displayed in both
+modes: especially messages concerning environment or
+internal errors, with version identification. When an
+end user is confronted to such a message, he may refer
+to a configuration documentation or send the message to
+the people in charge of SALOME installation, or to the
+development team, following the kind of error.
+
+C++ Macros for trace and debug
+------------------------------
+
+SALOME provides C++ macros for trace and debug. These
+macros are in::
+
+ KERNEL_SRC/src/SALOMELocalTrace/utilities.h
+
+This file must be included in C++ source. Some
+macros are activated only in debug mode, others are
+always activated. To activate the debug mode, ``_DEBUG_``
+must be defined, which is the case when SALOME
+Makefiles are generated from configure, without
+options. When ``_DEBUG_`` is undefined (release mode:
+``configure --disable-debug --enable-production``), the
+debug mode macros are defined empty (they do nothing).
+So, when switching from debug to release, it is
+possible (and recommended) to let the macro calls
+unchanged in the source.
+
+All the macros generate trace messages, stored in a
+circular buffer pool. A separate thread reads the
+messages in the buffer pool, and, depending on options
+given at SALOME start, writes the messages on the
+standard output, a file, or send them via CORBA, in
+case of a multi machine configuration.
+
+Three informations are systematically added in front of
+the information displayed:
+
+* the thread number from which the message come from;
+
+* the name of the source file in which the macros is set;
+
+* the line number of the source file at which the macro
+ is set.
+
+Macros defined in debug and release modes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**INFOS_COMPILATION**
+ The C++ macro INFOS_COMPILATION writes on the trace
+ buffer pool informations about the compiling process:
+
+ * the name of the compiler : g++, KCC, CC, pgCC;
+
+ * the date and the time of the compiling processing process.
+
+ This macro INFOS_COMPILATION does not have any
+ argument. Moreover, it is defined in both compiling
+ mode : _DEBUG_ and _RELEASE_.
+
+ Example::
+
+ #include "utilities.h"
+ int main(int argc , char **argv)
+ {
+ INFOS_COMPILATION;
+ ...
+ }
+ INFOS(str)
+
+**INFOS**
+ In both compiling mode _DEBUG_ and _RELEASE_, The C++
+ macro INFOS writes on the trace buffer pool the string
+ which has been passed in argument by the user.
+
+ Example::
+
+ #include "utilities.h"
+ int main(int argc , char **argv)
+ {
+ ...
+ INFOS("NORMAL END OF THE PROCESS");
+ return 0;
+ }
+
+ displays::
+
+ main.cxx [5] : NORMAL END OF THE PROCESS
+
+
+**INTERRUPTION(str)**
+ In both compiling mode _DEBUG_ and _RELEASE_, The C++
+ macro INTERRUPTION writes on the trace buffer pool the
+ string, with a special ABORT type. When the thread in
+ charge of collecting messages finds this message, it
+ terminates the application, after message treatment.
+
+**IMMEDIATE_ABORT(str)**
+ In both compiling mode _DEBUG_ and _RELEASE_, The C++
+ macro IMMEDIATE_ABORT writes the message str immediately on
+ standard error and exits the application. Remaining
+ messages not treated by the message collector thread
+ are lost.
+
+Macros defined only in debug mode
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**MESSAGE(str)**
+ In _DEBUG_ compiling mode only, the C++ macro MESSAGE
+ writes on the trace buffer pool the string which has
+ been passed in argument by the user. In _RELEASE_
+ compiling mode, this macro is blank.
+
+ Example::
+
+ #include "utilities.h"
+ #include <string>
+
+ using namespace std;
+
+ int main(int argc , char **argv)
+ {
+ ...
+ const char *str = "Salome";
+ MESSAGE(str);
+ ... const string st;
+ st = "Aster";
+ MESSAGE(c_str(st+" and CASTEM"));
+ return 0;
+ }
+
+ displays::
+
+ - Trace main.cxx [8] : Salome
+ - Trace main.cxx [12] : Aster and CASTEM
+
+**BEGIN_OF(func_name)**
+ In _DEBUG_ compiling mode, The C++ macro BEGIN_OF
+ appends the string "Begin of " to the one passed in
+ argument by the user and displays the result on the
+ trace buffer pool. In _RELEASE_ compiling mode, this
+ macro is blank.
+
+ Example::
+
+ #include "utilities.h"
+ int main(int argc , char **argv)
+ {
+ BEGIN_OF(argv[0]);
+ return 0;
+ }
+
+ displays::
+
+ - Trace main.cxx [3] : Begin of a.out
+
+
+**END_OF(func_name)**
+ In _DEBUG_ compiling mode, The C++ macro END_OF appends
+ the string "Normal end of " to the one passed in
+ argument by the user and displays the result on the
+ trace buffer pool. In _RELEASE_ compiling mode, this
+ macro is blank.
+
+ Example::
+
+ #include "utilities.h"
+ int main(int argc , char **argv)
+ {
+ END_OF(argv[0]);
+ return 0;
+ }
+
+ displays::
+
+ - Trace main.cxx [4] : Normal end of a.out
+
+**SCRUTE(var)**
+ In _DEBUG_ compiling mode, The C++ macro SCRUTE
+ displays its argument which is an application variable
+ followed by the value of the variable. In _RELEASE_
+ compiling mode, this macro is blank.
+
+ Example::
+
+ #include "utilities.h"
+ int main(int argc , char **argv)
+ {
+ const int i=999;
+ if( i > 0 ) SCRUTE(i) ; i=i+1;
+ return 0;
+ }
+
+ displays::
+
+ - Trace main.cxx [5] : i=999
+
+**ASSERT(condition)**
+ In _DEBUG_ compiling mode only, The C++ macro ASSERT
+ checks the expression passed in argument to be not
+ NULL. If it is NULL the condition is written with the
+ macro INTERRUPTION (see above). The process exits after
+ trace of this last message. In _RELEASE_ compiling
+ mode, this macro is blank. N.B. : if ASSERT is already
+ defined, this macro is ignored.
+
+ Example::
+
+ #include "utilities.h"
+ ...
+ const char *ptrS = fonc();
+ ASSERT(ptrS!=NULL);
+ cout << strlen(ptrS);
+ float table[10];
+ int k;
+ ...
+ ASSERT(k<10);
+ cout << table[k];
+
+Exceptions
+==========
+
+C++ exceptions: class SALOME_Exception
+--------------------------------------
+
+definition
+~~~~~~~~~~
+
+The class SALOME_Exception provides a generic method to
+send a message, with optional source file name and line
+number. This class is intended to serve as a base class
+for all kinds of exceptions SALOME code. All the
+exceptions derived from SALOME_Exception could be
+handled in a single catch, in which the message
+associated to the exception is displayed, or sent to a
+log file.
+
+The class SALOME_Exception inherits its behavior from
+the STL class exception.
+
+usage
+~~~~~
+
+The header SALOME/src/utils/utils_SALOME_Exception.hxx
+must be included in the C++ source, when raised or trapped::
+
+ #include "utils_SALOME_Exception.hxx"
+
+The SALOME_Exception constructor is::
+
+ SALOME_Exception( const char *text,
+ const char *fileName=0,
+ const unsigned int lineNumber=0 );
+
+The exception is raised like this::
+
+ throw SALOME_Exception("my pertinent message");
+
+or like this::
+
+ throw SALOME_Exception(LOCALIZED("my pertinent message"));
+
+where LOCALIZED is a macro provided with
+``utils_SALOME_Exception.hxx`` which gives file name and
+line number.
+
+The exception is handled like this::
+
+ try
+ {
+ ...
+ }
+ catch (const SALOME_Exception &ex)
+ {
+ cerr << ex.what() <<endl;
+ }
+
+The what() method overrides the one defined in the STL
+exception class.
+
+CORBA exceptions
+----------------
+
+definition
+~~~~~~~~~~
+
+The idl SALOME_Exception provides a generic CORBA
+exception for SALOME, with an attribute that gives an
+exception type,a message, plus optional source file
+name and line number.
+
+This idl is intended to serve for all user CORBA
+exceptions raised in SALOME code, as IDL specification
+does not support exception inheritance. So, all the
+user CORBA exceptions from SALOME could be handled in a
+single catch.
+
+The exception types defined in idl are:
+
+ - COMM CORBA communication problem,
+
+ - BAD_PARAM Bad User parameters,
+
+ - INTERNAL_ERROR application level problem (often irrecoverable).
+
+CORBA system and user exceptions already defined in the
+packages used within SALOME, such as OmniORB
+exceptions, must be handled separately.
+
+usage
+~~~~~
+
+CORBA servant, C++
+^^^^^^^^^^^^^^^^^^
+
+ The CORBA Server header for SALOME_Exception and a
+ macro to throw the exception are provided with the
+ header ``KERNEL_SRC/src/Utils/Utils_CorbaException.hxx``::
+
+ #include "Utils_CorbaException.hxx"
+
+ The exception is raised with a macro which appends file
+ name and line number::
+
+ if (myStudyName.size() == 0)
+ THROW_SALOME_CORBA_EXCEPTION("No Study Name given",
+ SALOME::BAD_PARAM);
+
+CORBA Client, GUI Qt C++
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+ **NO MORE AVAILABLE in SALOME 3.x**
+
+ The CORBA Client header for SALOME_Exception and a Qt
+ function header that displays a message box are
+ provided in:
+
+ ``KERNEL_SRC/src/SALOMEGUI/SALOMEGUI_QtCatchCorbaException.hxx``
+
+ ::
+
+ #include "SALOMEGUI_QtCatchCorbaException.hxx"
+
+ A typical exchange with a CORBA Servant will be::
+
+ try
+ {
+ ... // one ore more CORBA calls
+ }
+
+ catch (const SALOME::SALOME_Exception & S_ex)
+ {
+ QtCatchCorbaException(S_ex);
+ }
+
+
+
+CORBA Client, C++, without GUI
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+ Nothing specific has been provided to the developer
+ yet. See the idl or the Qt function
+ SALOMEGUI_QtCatchCorbaException.hxx to see how to get
+ the information given by the exception object.
+
+Miscellaneous tools
+===================
+
+Singleton
+---------
+
+Definition
+~~~~~~~~~~
+
+A singleton is an application data which is created and
+deleted only once at the end of the application
+process. The C++ compiler allows the user to create a
+static singleton data before the first executable
+statement. They are deleted after the last statement execution.
+
+The ``SINGLETON_`` template class deals with dynamic
+singleton. It is useful for functor objects. For
+example, an object that connects the application to a
+system at creation and disconnects the application at deletion.
+
+Usage
+~~~~~
+
+To create a single instance of a POINT object::
+
+ # include "Utils_SINGLETON.hxx"
+ ...
+ POINT *ptrPoint=SINGLETON_<POINT>::Instance() ;
+ assert(ptrPoint!=NULL) ;
+
+No need to delete ptrPoint. Deletion is achieved
+automatically at exit. If the user tries to create more
+than one singleton by using the class method
+SINGLETON_<TYPE>::Instance(), the pointer is returned
+with the same value even if this is done in different
+functions (threads ?)::
+
+ POINT *p1=SINGLETON_<POINT>::Instance() ;
+ ...
+ POINT *p2=SINGLETON_<POINT>::Instance() ;
+
+ assert(p1==p2)
+
+Design description
+~~~~~~~~~~~~~~~~~~
+
+Here are the principles features of the singleton
+design:
+
+* the user creates an object of class TYPE by using the
+ class method ``SINGLETON_<TYPE>::Instance()`` which
+ returns a pointer to the single object ;
+
+* to create an object, ``SINGLETON_<TYPE>::Instance()``
+ uses the default constructor of class TYPE ;
+
+* at the same time, this class method creates a
+ destructor object which is added to the generic list
+ of destructor objects to be executed at the end of
+ the application (atexit) ;
+
+* at the end of the application process all the
+ deletions are performed by the ``Nettoyage()`` C function
+ which executes the destruction objects end then
+ deletes the destructions objects themselves ;
+
+* the ``Nettoyage()`` C function using ``atexit()`` C function
+ is embedded in a static single object ``ATEXIT_()``.
+
+
+-------------------------------------------------------------------------------
+
++----------------------------------+------------------------------------------+
+| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ |
++----------------------------------+------------------------------------------+
+
+.. _`General KERNEL documentation`: ./index.html
+.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html
--- /dev/null
+/*
+:Authors: David Goodger, David Abrahams
+:Contact: goodger@users.sourceforge.net, dave@boost-consulting.com
+:date: $Date$
+:version: $Revision$
+:copyright: This stylesheet has been placed in the public domain.
+
+This stylesheet is for the use of ReStructuredText in a Boost context.
+It is basically an agglomeration of boost.css and the default.css that
+comes from docutils.
+
+ */
+
+.first {
+ margin-top: 0 }
+
+.last {
+ margin-bottom: 0 }
+
+a.toc-backref {
+ text-decoration: none ;
+ color: #00008B }
+
+dd {
+ margin-bottom: 0.5em }
+
+div.abstract {
+ margin: 2em 5em }
+
+div.abstract p.topic-title {
+ font-weight: bold ;
+ text-align: center }
+
+div.attention, div.caution, div.danger, div.error, div.hint,
+div.important, div.note, div.tip, div.warning, div.admonition {
+ margin: 2em ;
+ border: medium outset ;
+ padding: 1em }
+
+div.attention p.admonition-title, div.caution p.admonition-title,
+div.danger p.admonition-title, div.error p.admonition-title,
+div.warning p.admonition-title {
+ color: red ;
+ font-weight: bold ;
+ font-family: sans-serif }
+
+div.hint p.admonition-title, div.important p.admonition-title,
+div.note p.admonition-title, div.tip p.admonition-title,
+div.admonition p.admonition-title {
+ font-weight: bold ;
+ font-family: sans-serif }
+
+div.dedication {
+ margin: 2em 5em ;
+ text-align: center ;
+ font-style: italic }
+
+div.dedication p.topic-title {
+ font-weight: bold ;
+ font-style: normal }
+
+div.figure {
+ margin-left: 2em }
+
+div.footer, div.header {
+ font-size: smaller }
+
+div.sidebar {
+ margin-left: 1em ;
+ border: medium outset ;
+ padding: 0em 1em ;
+ background-color: #ffffee ;
+ width: 40% ;
+ float: right ;
+ clear: right }
+
+div.sidebar p.rubric {
+ font-family: sans-serif ;
+ font-size: medium }
+
+div.system-messages {
+ margin: 5em }
+
+div.system-messages h1 {
+ color: red }
+
+div.system-message {
+ border: medium outset ;
+ padding: 1em }
+
+div.system-message p.system-message-title {
+ color: red ;
+ font-weight: bold }
+
+div.topic {
+ margin: 2em }
+
+H1.title
+{
+ FONT-SIZE: 150%;
+ COLOR: #00008B;
+ text-align: center
+}
+H1
+{
+ FONT-SIZE: 125%;
+}
+H2
+{
+ FONT-SIZE: 108%;
+}
+h2.subtitle {
+ text-align: center }
+H3
+{
+ FONT-SIZE: 100%;
+}
+BODY
+{
+ FONT-SIZE: 100%;
+ BACKGROUND-COLOR: #ffffff;
+}
+PRE
+{
+ MARGIN-LEFT: 2em;
+ FONT-FAMILY: Courier;
+}
+CODE
+{
+ FONT-FAMILY: Courier;
+ white-space: pre;
+}
+.pre
+{
+ FONT-FAMILY: Courier;
+ white-space: pre;
+}
+.index
+{
+ TEXT-ALIGN: left;
+}
+.page-index
+{
+ TEXT-ALIGN: left;
+}
+.definition
+{
+ TEXT-ALIGN: left;
+}
+.footnote
+{
+ FONT-SIZE: 66%;
+ VERTICAL-ALIGN: super;
+ TEXT-DECORATION: none;
+}
+.function-semantics
+{
+ CLEAR: left;
+}
+
+hr {
+ width: 75% }
+
+ol.simple, ul.simple {
+ margin-bottom: 1em }
+
+ol.arabic {
+ list-style: decimal }
+
+ol.loweralpha {
+ list-style: lower-alpha }
+
+ol.upperalpha {
+ list-style: upper-alpha }
+
+ol.lowerroman {
+ list-style: lower-roman }
+
+ol.upperroman {
+ list-style: upper-roman }
+
+p.attribution {
+ text-align: right ;
+ margin-left: 50% }
+
+p.caption {
+ font-style: italic }
+
+p.credits {
+ font-style: italic ;
+ font-size: smaller }
+
+p.label {
+ white-space: nowrap }
+
+p.rubric {
+ font-weight: bold ;
+ font-size: larger ;
+ color: maroon ;
+ text-align: center }
+
+p.sidebar-title {
+ font-family: sans-serif ;
+ font-weight: bold ;
+ font-size: larger }
+
+p.sidebar-subtitle {
+ font-family: sans-serif ;
+ font-weight: bold }
+
+p.topic-title {
+ font-weight: bold }
+
+pre.address {
+ margin-bottom: 0 ;
+ margin-top: 0 ;
+ font-family: serif ;
+ font-size: 100% }
+
+pre.line-block {
+ font-family: serif ;
+ font-size: 100% }
+
+pre.literal-block, pre.doctest-block {
+ margin-left: 2em ;
+ margin-right: 2em ;
+ font-size: 80%;
+ border: solid thin gray ;
+ background-color: #eeeeee }
+
+span.classifier {
+ font-family: sans-serif ;
+ font-style: oblique }
+
+span.classifier-delimiter {
+ font-family: sans-serif ;
+ font-weight: bold }
+
+span.interpreted {
+ font-family: sans-serif }
+
+span.option {
+ white-space: nowrap }
+
+span.option-argument {
+ font-style: italic }
+
+span.pre {
+ white-space: pre }
+
+span.problematic {
+ color: red }
+
+table {
+ margin-top: 0.5em ;
+ margin-bottom: 0.5em }
+
+table.citation {
+ border-left: solid thin gray ;
+ padding-left: 0.5ex }
+
+table.docinfo {
+ margin: 2em 4em }
+
+table.footnote {
+ border-left: solid thin black ;
+ padding-left: 0.5ex }
+
+td, th {
+ padding-left: 0.5em ;
+ padding-right: 0.5em ;
+ vertical-align: top }
+
+th.docinfo-name, th.field-name {
+ font-weight: bold ;
+ text-align: left ;
+ white-space: nowrap }
+
+/*
+ dwa 2003/7/29 -- commented out so that it wouldn't override earlier
+ styles from boost.css
+
+h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
+ font-size: 100% }
+*/
+
+ul.auto-toc {
+ list-style-type: none }
--- /dev/null
+#!/bin/sh
+# Copyright (C) 2007-2010 CEA/DEN, EDF R&D, OPEN CASCADE
+#
+# Copyright (C) 2003-2007 OPEN CASCADE, EADS/CCR, LIP6, CEA/DEN,
+# CEDRAT, EDF R&D, LEG, PRINCIPIA R&D, BUREAU VERITAS
+#
+# This library is free software; you can redistribute it and/or
+# modify it under the terms of the GNU Lesser General Public
+# License as published by the Free Software Foundation; either
+# version 2.1 of the License.
+#
+# This library is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# Lesser General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public
+# License along with this library; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+#
+# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
+#
+
+# ===================================================================
+# This shell script is provided for generating the html files
+# from the txt files (restructured text) in the source directory.
+# Usage: just execute the script where it stands in the source
+# directory. The file list has to be updated manually when adding
+# a new restructured text file.
+# Note that the building process executes a target rstdoc that
+# generates the html documentation without need of this script.
+# The autoconficuration (check_htmlgen.m4) set the correct generator
+# rst2html by replacing the @RST2HTML@ tag.
+# ===================================================================
+# (CSSI - gboulant - 25/10/05)
+# This must be updated manually in this script (for source usage only)
+#
+RST2HTML=rst2html
+
+FILELIST="index
+ UnitTests
+ SALOME_Application
+ INSTALL
+ kernel_resources
+ userguide"
+
+STYLESHEET=rst.css
+RSTOPTS="--output-encoding=latin1 --stylesheet=$STYLESHEET"
+
+for file in $FILELIST; do
+ bfn=`basename $file .txt`
+ echo "Generating ${bfn}.html from ${bfn}.txt ..."
+ $RST2HTML $RSTOPTS ${bfn}.txt ${bfn}.html
+done
+
--- /dev/null
+=================================================================
+User's guide, for developpers and users
+=================================================================
+
+*html version of this document is produced with docutils*::
+
+ rst2html < doc.txt > doc.html
+
+*This document corresponds to SALOME2 3.1.0*
+*NOT UP TO DATE with 3.2.0*
+
+.. contents::
+.. sectnum::
+
++-------------------------------------------+
+| **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
++-------------------------------------------+
+
+-------------------------------------------------------------------------------
+
+This guide provides you with some basic concepts for developing and
+using the SALOME platform. You will find some information on the
+general technical architecture ...
+
+Introduction
+============
+
+General information
+-------------------
+
+This document has been initialized by collecting and updating an existing
+documentation. The restructured text format has been selected for
+writing. This format can be read with a basic editor except for
+pictures and some hypertext links. You can build the html pages using
+the docutils scripts provided with python packages on most platform.
+
+Definitions
+-----------
+
+``WORK IN PROGRESS``
+
+Module
+ definition of a module and/or link to the definition
+
+Container
+ definition of a container
+
+
+General concepts
+================
+modules et dépendances (s'inspirer de PYHELLO)
+
+
+Filesystem organisation
+========================
+
+Voir doc de JR "Organisation de la plate-forme"
+
+A typical source working directory
+----------------------------------
+organisation type des sources d'un module standard (spécifications techniques)
+
+A typical installation directory
+--------------------------------
+organisation type des produits installés
+
+
+Building process
+================
+Procédures de compilation (renvoie au install.sh)
+
+
+Developer's guide - basic concepts
+=========================================
+
+Guide du développeur: éléments de conception
+ - zoom sur certains éléments techniques bons à connaitre pour faire
+ évoluer le KERNEL sans tout casser.
+ - les ressources du kernel:
+ - trace, debug, exception (cf. kernel_ressources.tex)
+ - classes batch (présentation puis renvoi à la doc d'Ivan)
+ - développement de tests unitaires
+
+Developer's guide - managing the development space
+==================================================
+
+- Guide du développeur: gestion de l'espace de développement
+ - principe de mise en oeuvre (rôle des étapes: build_configure, ...)
+ - description des fichiers m4 et du principe de mise en oeuvre
+ - les Makefile.in, ... (cf. doc guide du développeur).
+ - évolution des procédures de construction
+ - personalisation des procédures de construction
+
+Developer' guide - integration tools
+====================================
+- Guide de l'intégrateur (développeur de nouveaux modules)
+(on lui montre ici le principe de construction et les ressources à
+disposition pour faire le travail)
+ - création d'un modules
+ - intégration code boîte noire (perfect, solver)
+ - intégration bibliothèque de fonctions (hxx2salome, voir avec
+ N.Crouzet)
+ - intégration de modèles de données (xdata)
+
+
+End user's guide
+================
+- Guide de l'utilisateur
+ - concept d'application (renvoie doc Paul)
+ - commandes avancées (showNS, exemple de contact de la
+ session, d'un engine, utilisation du lifeCycle, du module salome,
+ des modules geompy et smesh)
+ - utilisation en mode distribué (doc de B. Sechet)
+ - GUI and TUI documentation
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+RST Exemples
+============
+
+See INSTALL_ for general information on required configuration and
+prerequisites, compilation procedure, setting environment principles.
+
+.. _INSTALL: ./INSTALL.html
+
+
+-------------------------------------------------------------------------------
+
++----------------------------------+------------------------------------------+
+| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ |
++----------------------------------+------------------------------------------+
+
+.. _`General KERNEL documentation`: ./index.html
+.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html
--- /dev/null
+# -*- coding: iso-8859-1 -*-
+#
+# yacs documentation build configuration file, created by
+# sphinx-quickstart on Fri Aug 29 09:57:25 2008.
+#
+# This file is execfile()d with the current directory set to its containing dir.
+#
+# The contents of this file are pickled, so don't put values in the namespace
+# that aren't pickleable (module imports are okay, they're removed automatically).
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+import sys, os
+
+# If your extensions are in another directory, add it here. If the directory
+# is relative to the documentation root, use os.path.abspath to make it
+# absolute, like shown here.
+#sys.path.append(os.path.abspath('.'))
+
+# General configuration
+# ---------------------
+
+# Add any Sphinx extension module names here, as strings. They can be extensions
+# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
+extensions = ['sphinx.ext.autodoc']
+
+# Uncomment the following line to build the links with Python documentation
+# (you might need to set http_proxy environment variable for this to work)
+#extensions += ['sphinx.ext.intersphinx']
+
+# Intersphinx mapping to add links to modules and objects in the Python
+# standard library documentation
+intersphinx_mapping = {'http://docs.python.org': None}
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix of source filenames.
+source_suffix = '.rst'
+
+# The encoding of source files.
+source_encoding = 'utf-8'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = 'KERNEL python packages'
+copyright = '2010 EDF R&D'
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+#
+# The short X.Y version.
+version = '5.1.4'
+# The full version, including alpha/beta/rc tags.
+release = '5.1.4'
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+language = 'en'
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+#today = ''
+# Else, today_fmt is used as the format for a strftime call.
+#today_fmt = '%B %d, %Y'
+
+# List of documents that shouldn't be included in the build.
+#unused_docs = []
+
+# List of directories, relative to source directory, that shouldn't be searched
+# for source files.
+exclude_trees = ['.build','ref','images','CVS','.svn']
+
+# The reST default role (used for this markup: `text`) to use for all documents.
+#default_role = None
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+#add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+#add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+#show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+
+# Options for HTML output
+# -----------------------
+
+# The theme to use for HTML and HTML Help pages. Major themes that come with
+# Sphinx are currently 'default' and 'sphinxdoc'.
+html_theme = 'default'
+#html_theme = 'nature'
+#html_theme = 'agogo'
+#html_theme = 'sphinxdoc'
+#html_theme = 'omadoc'
+
+# Add any paths that contain custom themes here, relative to this directory.
+#html_theme_path = ['themes']
+
+# The name for this set of Sphinx documents. If None, it defaults to
+# "<project> v<release> documentation".
+#html_title = None
+
+# A shorter title for the navigation bar. Default is the same as html_title.
+#html_short_title = None
+
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+#html_logo = None
+
+# The name of an image file (within the static path) to use as favicon of the
+# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
+# pixels large.
+#html_favicon = None
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+#html_static_path = ['_static']
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+#html_last_updated_fmt = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+#html_use_smartypants = True
+
+# Custom sidebar templates, maps document names to template names.
+#html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {}
+
+# If false, no module index is generated.
+html_use_modindex = False
+
+# If false, no index is generated.
+#html_use_index = True
+
+# If true, the index is split into individual pages for each letter.
+#html_split_index = False
+
+# If true, the reST sources are included in the HTML build as _sources/<name>.
+html_copy_source = True
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it. The value of this option must be the
+# base URL from which the finished HTML is served.
+#html_use_opensearch = ''
+
+# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml").
+#html_file_suffix = ''
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'kernelpydoc'
+
+
+# Options for LaTeX output
+# ------------------------
+
+# The paper size ('letter' or 'a4').
+latex_paper_size = 'a4'
+
+# The font size ('10pt', '11pt' or '12pt').
+latex_font_size = '10pt'
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title, author, document class [howto/manual]).
+latex_documents = [
+ ('index', 'kernelpy.tex', 'Documentation of the KERNEL python packages', 'EDF R\&D', 'manual')
+]
+
+# The name of an image file (relative to this directory) to place at the top of
+# the title page.
+latex_logo = '../salome/tui/images/head.png'
+
+# For "manual" documents, if this is true, then toplevel headings are parts,
+# not chapters.
+#latex_use_parts = True
+
+# Additional stuff for the LaTeX preamble.
+#latex_preamble = ''
+
+# Documents to append as an appendix to all manuals.
+#latex_appendices = []
+
+# If false, no module index is generated.
+latex_use_modindex = False
--- /dev/null
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+ Documentation of the programming interface (API)
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+This section describes the python packages and modules of the
+``salome.kernel`` python package. The main part is generated from the
+code documentation included in source python files.
+
+:mod:`salome.kernel` -- Package containing the KERNEL python utilities
+======================================================================
+
+:mod:`deprecation` -- Indication of deprecated modules and functions
+--------------------------------------------------------------------
+
+.. automodule:: salome.kernel.deprecation
+ :members:
+
+
+:mod:`termcolor` -- Display colored text in terminal
+----------------------------------------------------
+
+.. automodule:: salome.kernel.termcolor
+ :members:
+ :exclude-members: TEST_termcolor
+
+
+:mod:`logger` -- Logging utility
+--------------------------------
+
+.. automodule:: salome.kernel.logger
+
+.. autoclass:: Logger
+ :members:
+ :show-inheritance:
+
+.. autoclass:: ExtLogger
+ :members:
+ :show-inheritance:
+
+
+:mod:`studyedit` -- Study editor
+--------------------------------
+
+.. automodule:: salome.kernel.studyedit
+ :members:
--- /dev/null
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+ Documentation of the KERNEL python packages
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+Main documentation
+==================
+
+.. toctree::
+ :maxdepth: 3
+
+ overview.rst
+ docapi.rst
+
+
+Additional documentation
+========================
+
+.. toctree::
+ :maxdepth: 3
+
+ salomepypkg.rst
--- /dev/null
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+General presentation of the KERNEL python package
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+The KERNEL python package essentially contains:
+
+* Helper functions to manipulate KERNEL objects from python. For
+ example, the ``studyedit.py`` module makes you ease with the
+ manipulation of the SALOME study, its ``SComponent`` and
+ ``SObject``.
+* General purpose functions for logging, threading, and other recurent
+ stuff in python programming. These function has no dependancy with
+ SALOME and could be used from any python interpreter
+
+Note that these functions either encapsulate the python programming
+interface of KERNEL core (the CORBA or SWIG interfaces for example) or
+extend existing utilities as the ``salome*.py`` modules.
+
+The functions are distributed in the python package
+``salome.kernel``. For example, the usage of the study editor to
+manipulate some objects can be done with a set of instructions as:
+
+.. code-block:: python
+
+ import salome
+ salome.salome_init()
+ salomeStudyId = salome.myStudyId
+
+ from salome.kernel import studyedit
+ studyEditor = studyedit.getStudyEditor(salomeStudyId)
+
+ myStudyComponent = studyEditor.findOrCreateComponent(
+ componentName,
+ componentLabel,
+ componentIcon,
+ engineName)
+
+ myStudyItem = studyEditor.createItem(
+ myStudyComponent,
+ itemName,
+ itemComment,
+ itemType,
+ itemIcon)
+
+The specification of the programming interface of this package is
+detailled in the part :doc:`Documentation of the programming interface
+(API)</docapi>` of this documentation.
+
+.. note::
+ The main package ``salome`` contains other sub-packages that are
+ distributed with the other SALOME modules. For example, the GEOM
+ module provides the python package ``salome.geom`` and SMESH the
+ package ``salome.smesh``.
--- /dev/null
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+Complement A: Organizing the SALOME python functions in a packaged structure
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+This chapter contains the instruction notes to organise the python
+files of SALOME in a packaged python structure. This is the first step
+of the development process, whose goal is to validate the principles
+and show a possible way.
+
+:Contacts: Guillaume Boulant, Christian Caremoli, Renaud Barate
+
+Objectives
+==========
+
+The main idea is to import SALOME python functions by doing:
+
+.. code-block:: python
+
+ from salome.kernel.<myPythonModule> import <myFunction>
+
+instead of:
+
+.. code-block:: python
+
+ from <myPythonModule> import <myFunction>
+
+as it must be done up to now because of the flat organisation of
+python files in the installation folders of SALOME modules.
+
+To reach this target, the files ``<myPythonModule>.py`` have to be
+organised in a packaged python structure where the main package is
+named ``salome``, and then sub-packages could be created for each
+SALOME module:
+
+* ``salome.kernel``: for kernel python functions, embedded in the
+ KERNEL module
+* ``salome.gui``: for gui python functions, embedded in the GUI module
+* ``salome.geom``: for geom python functions, embedded in the GEOM
+ module
+* and so on ...
+
+The motivations of this objective are twice:
+
+* Definitively prevent the risk of naming conflict between python
+ modules coming from different SALOME modules. Today, the developper
+ of a module has to take care of the names used in other modules to
+ choose a name.
+* Integrate in SALOME some python modules initialy developed in the
+ context of domain specific SALOME applications (SALOME-MECA,
+ SALOME-CFD, OPENTURN, PANTHERE) and whose source files are organized
+ in a packaged python structure.
+
+The starting point then is a python library named ``nepal`` that
+provides SALOME helper functions classified by modules
+(KERNEL,GEOM,...) and organized in a packaged python structure:
+
+* ``salome.kernel``: helper functions for manipulating the SALOME
+ study and its components (SComponents and SObject). This provides
+ also general purpose utilities for logging and threading.
+* ``salome.gui``: helper functions to manipulate the graphical
+ representation of studies and the general behavior of the graphical
+ interface. This provides also generic templates for implementing
+ dialog box with the MVC pattern.
+* ``salome.geom``: essentially contains a function called
+ "visualization of structural elements". This is used by mechanical
+ ingeneers to create the 3D geometrical object corresponding to the
+ numerical model of a given structural element.
+* ``salome.smesh``: to manipulated smesh data handled from the SObject
+ in the SALOME study.
+
+The target point is to have the ``salome.kernel`` part in the KERNEL
+module, the ``salome.geom`` part in the GEOM module, and so on. And
+with **no impact on SALOME scripts** that already exists (import salome,
+and all other stuff should be imported and work as before).
+
+
+Problems
+========
+
+To reach this target, we have to face two problems:
+
+* A naming conflict with the instruction ``import salome``. The result
+ is unpredictible because of the existance in the ``sys.path`` of
+ both a file ``salome.py`` and a package ``salome``.
+* The dispatching of ``salome.*`` sub-packages in the different SALOME
+ modules.
+
+Naming conflict between ``salome.py`` module and ``salome`` package
+-------------------------------------------------------------------
+
+The problem is solved by installing the ``salome.py`` file under the
+name ``__init__.py`` in a folder named ``${salomepythondir}/salome``.
+
+By this operation, the ``${salomepythondir}/salome`` directory is
+transformed in a python package and the instruction ``import salome``
+do the same things as before this modification, without any
+modification of the ``sys.path``.
+
+Dispatching of ``salome.*`` sub-packages in different SALOME modules
+--------------------------------------------------------------------
+
+When we use a SALOME virtual application, the problem is naturally
+solved by the fact that every sub-packages are virtually installed in
+the same directory, the directory ``${salomepythondir}/salome``
+containing the file ``__init__.py``.
+
+Nevertheless, some people doesn't use the virtual application. To get
+a robust configuration in any case, one can use the python namespace
+pattern. This consists in creating a virtual python package that
+aggregates all the sub-packages.
+
+Technically speaking, this consists in implementing in the file
+``${salomepythondir}/salome/__init__.py`` (new version of
+``salome.py``) a function that automatically extend the ``__path__``
+variable with sub-packages that can be found in SALOME modules
+installation paths. The code looks something like that:
+
+.. code-block:: python
+
+ import os, sys
+
+ MATCH_ENDING_PATTERN="site-packages/salome"
+
+ def extend_path(pname):
+ for dir in sys.path:
+ if not isinstance(dir, basestring) or not os.path.isdir(dir) or not dir.endswith(MATCH_ENDING_PATTERN):
+ continue
+ subdir = os.path.join(dir, pname)
+ # WARN: This may still add duplicate entries to path on
+ # case-insensitive filesystems
+ if os.path.isdir(subdir) and subdir not in __path__:
+ print "INFO - The directory %s is appended to sys.path" % subdir
+ __path__.append(subdir)
+
+ extend_path(ROOT_PYTHONPACKAGE_NAME)
+
+
+Adaptation of the ``apply_gen`` utility
+----------------------------------------
+
+Due to the specific above choices, the ``apply_gen`` utility must be
+modified so that the sub-folder ``salome`` in ``${salomepythondir}``
+is not generated as a symbolic link any longer but as a real folder
+containing symbolic links towards the module specific python
+sub-packages (``kernel``, ``geom``, ``smesh``, ...) and to the single
+file ``__init__.py`` provided by the KERNEL module.
+
+This adaptation can be done in the ``virtual_salome.py`` script.
+
+
+What to do with already existing python files?
+----------------------------------------------
+
+Do nothing at this step, it works fine because the files are installed
+in a path included in the ``sys.path``.
+
+In a future version, it should be nice to reverse all the python files
+of the KERNEL library in this packaged structure. But this can't be
+done without impact on existing python user scripts.
+
+Instructions
+============
+
+Instructions for creating the python packages
+---------------------------------------------
+
+Considering the elements described above, a procedure that works to
+get the packaged python structure is:
+
+* Rename the file ``salome.py`` in ``__init__.py`` (and adapt the
+ Makefile.am). This is located in the source directory
+ ``src/KERNEL_PY``.
+* Copy the sources files of the kernel part in the source directory
+ ``src/KERNEL_PY`` starting with a stage named ``kernel`` including
+ its own packaged structure (only python files and a file
+ ``__init__.py`` for now)
+* Copy the sources files of the geom part in the source directory
+ ``src/GEOM_PY`` (to be created) of the GEOM module. In this case, we
+ copy the python files directly in the directory (no stage named
+ ``geom``, it's not required for source organisation, and will be
+ created only for installation by makefile).
+* Apply the same procedure for every other SALOME modules (it concerns
+ only SMESH up to now).
+* Apply the "namespace pattern" by implementing and invoking the
+ ``extend_path`` function in the newly created file ``__init__.py``
+* Adapt the ``apply_gen`` utility to take into account the finer
+ folder hierarchy in ``site-packages``.
+
+The naming convention for source folder is here the convention in
+place in the KERNEL module: the source code of the python packages of
+a SALOME module <MODULE_NAME> is located in the source directory
+``<srcdir>/src/<MODULE_NAME>_PY``.
+
+Note also that all python files that were existing in the KERNEL
+module are leaft untouched but the file ``salome.py``.
+
+Instructions for the associated documentation
+---------------------------------------------
+
+One special point for the documentation:
+
+* The documentation of the python package API is writen in rst
+ (restructured text) and generated form the source code with sphinx.
+* The rst source files are located in the directory
+ ``<srcdir>/doc/docutils``.
+* The html generated files are installed in the directory
+ ``<installdir>/share/doc/salome/docutils`` but are not connected to
+ the in-line documentation of the SALOME associated module (menu help
+ of the SALOME application).
+
+Any suggestion on this point would be appreciated.
+
+TODO (by someone):
+
+* Move all files ``*.txt`` from the ``<srcdir>/doc`` folder to the
+ ``<srcdir>/doc/docutils`` folder and analyse what is still to date
+ and usefull.
+* Integrate in this part the reference documentation of the ``salome``
+ utility and all documentation associated to the launching process
+ (in particular virtual application)
+* Connect this part of the documentation to the main part (doxygen
+ part).
+
+
+Synthesis
+---------
+
+Finaly, here is a synthesis of modifications in source files.
+
+Files modified:
+
+* See the CVS patch files KERNEL.patch, GEOM.patch and SMESH.patch
+ (the only SALOME modules modified today).
+
+Files to be added:
+
+* KERNEL: file ``src/KERNEL_PY/__init__.py`` (``salome.py`` renamed)
+* KERNEL: directory ``src/KERNEL_PY/kernel``
+* KERNEL: directory ``doc/docutils``
+* KERNEL: file ``salome_adm/unix/config_files/check_sphinx.m4``
+* GEOM : directory ``src/GEOM_PY``
+* GEOM : directory ``doc/docutils``
+* SMESH : directory ``src/SMESH_PY``
+* SMESH : directory ``doc/docutils``
+
+Files to be delete:
+
+* file ``src/KERNEL_PY/salome.py``
+
+
+Tests and usage
+===============
+
+The instructions above provides you with a SALOME application whose
+modules embed there dedicated python packages. This installation can
+can be tested using some test use cases. For example, the
+visualisation of structural elements (provided by the package
+``salome.geom`` can be tested by:
+
+.. code-block:: python
+
+ from salome.geom.structelem import TEST_StructuralElement
+ TEST_StructuralElement()
+
+This can be enter in the GUI python console or in a python interpreter
+executed in a SALOME session.
+
+For more details, read the API documentation in
+``<installdir>/share/doc/salome/docutils``.
+++ /dev/null
-=================================================================
-KERNEL common Services
-=================================================================
-
-*html version of this document is produced with docutils*::
-
- rst2html < doc.txt > doc.html
-
-*This document corresponds to SALOME2 3.2.0*
-
-.. contents::
-.. sectnum::
-
-+-------------------------------------------+
-| **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
-+-------------------------------------------+
-
--------------------------------------------------------------------------------
-
-**General information, for users, integrators and developers**
-
-**Users, integrators and developers, which documentation ?**
-
-Following your kind of usage of SALOME, you will find some specific
-introductory documentation, listed below.
-
-End user
-========
-
-How to configure a SALOME application
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The end user may have to configure his own SALOME application by selection of a
-subset of availables SALOME modules. He also may want to install his
-application on several computers.
-
-See SALOME_Application_ to define your own configuration of SALOME and run it
-on one or several computers. This is the recommended way of configuration.
-
-.. _SALOME_Application: ./SALOME_Application.html
-
-
-How to launch SALOME in a SALOME application
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-See SALOME_Application_.
-
-How to use KERNEL services in Python scripts
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The SALOME KERNEL offers offers a list of services available in Python.
-
-See KERNEL_Services_.
-
-.. _KERNEL_Services: ./KERNEL_Services.html
-
-Application Integrator
-======================
-
-Applications integrators are in charge of configuration and installation of
-specific SALOME applications over a local network. Application Integrators
-built SALOME modules binaries from sources tarballs.
-
-How to install SALOME
-~~~~~~~~~~~~~~~~~~~~~
-
-See INSTALL_ for general information on required configuration and
-prerequisites, compilation procedure, setting environment principles.
-
-.. _INSTALL: ./INSTALL.html
-
-How to configure a SALOME application
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-See SALOME_Application_ to define your own configuration of SALOME and run it
-on one or several computers. This is the recommended way of configuration.
-
-.. _SALOME_Application: ./SALOME_Application.html
-
-
-Module maintainer
-=================
-
-Module maintainers are in charge of the development and debug of the SALOME
-modules. Each SALOME module is stored in a CVS base. CVS bases are organised
-in separate branches for developments and debug. All official or development
-releases are identified by a CVS tag.
-
-Source code structuration and Unit Tests
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-See UnitTests_ for general information on code directories structure,
-unit tests associated to the different kind of classes, and how to run
-the unit tests.
-
-.. _UnitTests: ./UnitTests.html
-
-Some development utilities
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-See kernel_resources_ for information on basic utilities for C++ and Python
-development, like trace and debug, exceptions, singleton.
-
-.. _kernel_resources: ./kernel_resources.html
-
--------------------------------------------------------------------------------
-
-+----------------------------------+------------------------------------------+
-| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ |
-+----------------------------------+------------------------------------------+
-
-.. _`General KERNEL documentation`: ./index.html
-.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html
+++ /dev/null
-======================================================================
-SALOME Kernel resources for developer
-======================================================================
-
-*html version of this document is produced with docutils*::
-
- rst2html doc.txt > doc.html
-
-*This document corresponds to SALOME2 3.2.0*
-
-:Authors:
- Antoine Yessayan,
- Paul Rascle
-
-:Version: 0.3 - february 17, 2006
-
-+-------------------------------------------+
-| **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
-+-------------------------------------------+
-
--------------------------------------------------------------------------------
-
-**Abstract**
-
-This document describes the development environment for
-C++ and Python. Makefiles generation and usage are
-introduced in another document: "using the SALOME
-configuration and building system environment".
-Development environment is intended here as: trace and
-debug macros usage; SALOME exceptions usage, in C++ and
-Python; user CORBA exceptions usage, in C++ and Python,
-with and without Graphical User Interface; some general
-purpose services such as singleton, used for CORBA
-connection and disconnection.
-
-.. contents::
-.. sectnum::
-
--------------------------------------------------------------------------------
-
-Trace and debug Utilities
-=========================
-
-During the development process, an execution log is
-useful to identify problems. This log contains
-messages, variables values, source files names and line
-numbers. It is recommended to verify assertions on
-variables values and if necessary, to stop the
-execution at debug time, in order to validate all parts
-of code.
-
-Two modes: debug and release
-----------------------------
-
-The goal of debug mode is to check as many features as
-possible during the early stages of the development
-process. The purpose of the utilities provided in
-SALOME is to help the developer to add detailed traces
-and check variables values, without writing a lot of code.
-
-When the code is assumed to be valid, the release mode
-optimizes execution, in terms of speed, memory, and
-display only user level messages.
-
-But, some informations must always be displayed in both
-modes: especially messages concerning environment or
-internal errors, with version identification. When an
-end user is confronted to such a message, he may refer
-to a configuration documentation or send the message to
-the people in charge of SALOME installation, or to the
-development team, following the kind of error.
-
-C++ Macros for trace and debug
-------------------------------
-
-SALOME provides C++ macros for trace and debug. These
-macros are in::
-
- KERNEL_SRC/src/SALOMELocalTrace/utilities.h
-
-This file must be included in C++ source. Some
-macros are activated only in debug mode, others are
-always activated. To activate the debug mode, ``_DEBUG_``
-must be defined, which is the case when SALOME
-Makefiles are generated from configure, without
-options. When ``_DEBUG_`` is undefined (release mode:
-``configure --disable-debug --enable-production``), the
-debug mode macros are defined empty (they do nothing).
-So, when switching from debug to release, it is
-possible (and recommended) to let the macro calls
-unchanged in the source.
-
-All the macros generate trace messages, stored in a
-circular buffer pool. A separate thread reads the
-messages in the buffer pool, and, depending on options
-given at SALOME start, writes the messages on the
-standard output, a file, or send them via CORBA, in
-case of a multi machine configuration.
-
-Three informations are systematically added in front of
-the information displayed:
-
-* the thread number from which the message come from;
-
-* the name of the source file in which the macros is set;
-
-* the line number of the source file at which the macro
- is set.
-
-Macros defined in debug and release modes
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**INFOS_COMPILATION**
- The C++ macro INFOS_COMPILATION writes on the trace
- buffer pool informations about the compiling process:
-
- * the name of the compiler : g++, KCC, CC, pgCC;
-
- * the date and the time of the compiling processing process.
-
- This macro INFOS_COMPILATION does not have any
- argument. Moreover, it is defined in both compiling
- mode : _DEBUG_ and _RELEASE_.
-
- Example::
-
- #include "utilities.h"
- int main(int argc , char **argv)
- {
- INFOS_COMPILATION;
- ...
- }
- INFOS(str)
-
-**INFOS**
- In both compiling mode _DEBUG_ and _RELEASE_, The C++
- macro INFOS writes on the trace buffer pool the string
- which has been passed in argument by the user.
-
- Example::
-
- #include "utilities.h"
- int main(int argc , char **argv)
- {
- ...
- INFOS("NORMAL END OF THE PROCESS");
- return 0;
- }
-
- displays::
-
- main.cxx [5] : NORMAL END OF THE PROCESS
-
-
-**INTERRUPTION(str)**
- In both compiling mode _DEBUG_ and _RELEASE_, The C++
- macro INTERRUPTION writes on the trace buffer pool the
- string, with a special ABORT type. When the thread in
- charge of collecting messages finds this message, it
- terminates the application, after message treatment.
-
-**IMMEDIATE_ABORT(str)**
- In both compiling mode _DEBUG_ and _RELEASE_, The C++
- macro IMMEDIATE_ABORT writes the message str immediately on
- standard error and exits the application. Remaining
- messages not treated by the message collector thread
- are lost.
-
-Macros defined only in debug mode
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-**MESSAGE(str)**
- In _DEBUG_ compiling mode only, the C++ macro MESSAGE
- writes on the trace buffer pool the string which has
- been passed in argument by the user. In _RELEASE_
- compiling mode, this macro is blank.
-
- Example::
-
- #include "utilities.h"
- #include <string>
-
- using namespace std;
-
- int main(int argc , char **argv)
- {
- ...
- const char *str = "Salome";
- MESSAGE(str);
- ... const string st;
- st = "Aster";
- MESSAGE(c_str(st+" and CASTEM"));
- return 0;
- }
-
- displays::
-
- - Trace main.cxx [8] : Salome
- - Trace main.cxx [12] : Aster and CASTEM
-
-**BEGIN_OF(func_name)**
- In _DEBUG_ compiling mode, The C++ macro BEGIN_OF
- appends the string "Begin of " to the one passed in
- argument by the user and displays the result on the
- trace buffer pool. In _RELEASE_ compiling mode, this
- macro is blank.
-
- Example::
-
- #include "utilities.h"
- int main(int argc , char **argv)
- {
- BEGIN_OF(argv[0]);
- return 0;
- }
-
- displays::
-
- - Trace main.cxx [3] : Begin of a.out
-
-
-**END_OF(func_name)**
- In _DEBUG_ compiling mode, The C++ macro END_OF appends
- the string "Normal end of " to the one passed in
- argument by the user and displays the result on the
- trace buffer pool. In _RELEASE_ compiling mode, this
- macro is blank.
-
- Example::
-
- #include "utilities.h"
- int main(int argc , char **argv)
- {
- END_OF(argv[0]);
- return 0;
- }
-
- displays::
-
- - Trace main.cxx [4] : Normal end of a.out
-
-**SCRUTE(var)**
- In _DEBUG_ compiling mode, The C++ macro SCRUTE
- displays its argument which is an application variable
- followed by the value of the variable. In _RELEASE_
- compiling mode, this macro is blank.
-
- Example::
-
- #include "utilities.h"
- int main(int argc , char **argv)
- {
- const int i=999;
- if( i > 0 ) SCRUTE(i) ; i=i+1;
- return 0;
- }
-
- displays::
-
- - Trace main.cxx [5] : i=999
-
-**ASSERT(condition)**
- In _DEBUG_ compiling mode only, The C++ macro ASSERT
- checks the expression passed in argument to be not
- NULL. If it is NULL the condition is written with the
- macro INTERRUPTION (see above). The process exits after
- trace of this last message. In _RELEASE_ compiling
- mode, this macro is blank. N.B. : if ASSERT is already
- defined, this macro is ignored.
-
- Example::
-
- #include "utilities.h"
- ...
- const char *ptrS = fonc();
- ASSERT(ptrS!=NULL);
- cout << strlen(ptrS);
- float table[10];
- int k;
- ...
- ASSERT(k<10);
- cout << table[k];
-
-Exceptions
-==========
-
-C++ exceptions: class SALOME_Exception
---------------------------------------
-
-definition
-~~~~~~~~~~
-
-The class SALOME_Exception provides a generic method to
-send a message, with optional source file name and line
-number. This class is intended to serve as a base class
-for all kinds of exceptions SALOME code. All the
-exceptions derived from SALOME_Exception could be
-handled in a single catch, in which the message
-associated to the exception is displayed, or sent to a
-log file.
-
-The class SALOME_Exception inherits its behavior from
-the STL class exception.
-
-usage
-~~~~~
-
-The header SALOME/src/utils/utils_SALOME_Exception.hxx
-must be included in the C++ source, when raised or trapped::
-
- #include "utils_SALOME_Exception.hxx"
-
-The SALOME_Exception constructor is::
-
- SALOME_Exception( const char *text,
- const char *fileName=0,
- const unsigned int lineNumber=0 );
-
-The exception is raised like this::
-
- throw SALOME_Exception("my pertinent message");
-
-or like this::
-
- throw SALOME_Exception(LOCALIZED("my pertinent message"));
-
-where LOCALIZED is a macro provided with
-``utils_SALOME_Exception.hxx`` which gives file name and
-line number.
-
-The exception is handled like this::
-
- try
- {
- ...
- }
- catch (const SALOME_Exception &ex)
- {
- cerr << ex.what() <<endl;
- }
-
-The what() method overrides the one defined in the STL
-exception class.
-
-CORBA exceptions
-----------------
-
-definition
-~~~~~~~~~~
-
-The idl SALOME_Exception provides a generic CORBA
-exception for SALOME, with an attribute that gives an
-exception type,a message, plus optional source file
-name and line number.
-
-This idl is intended to serve for all user CORBA
-exceptions raised in SALOME code, as IDL specification
-does not support exception inheritance. So, all the
-user CORBA exceptions from SALOME could be handled in a
-single catch.
-
-The exception types defined in idl are:
-
- - COMM CORBA communication problem,
-
- - BAD_PARAM Bad User parameters,
-
- - INTERNAL_ERROR application level problem (often irrecoverable).
-
-CORBA system and user exceptions already defined in the
-packages used within SALOME, such as OmniORB
-exceptions, must be handled separately.
-
-usage
-~~~~~
-
-CORBA servant, C++
-^^^^^^^^^^^^^^^^^^
-
- The CORBA Server header for SALOME_Exception and a
- macro to throw the exception are provided with the
- header ``KERNEL_SRC/src/Utils/Utils_CorbaException.hxx``::
-
- #include "Utils_CorbaException.hxx"
-
- The exception is raised with a macro which appends file
- name and line number::
-
- if (myStudyName.size() == 0)
- THROW_SALOME_CORBA_EXCEPTION("No Study Name given",
- SALOME::BAD_PARAM);
-
-CORBA Client, GUI Qt C++
-^^^^^^^^^^^^^^^^^^^^^^^^
-
- **NO MORE AVAILABLE in SALOME 3.x**
-
- The CORBA Client header for SALOME_Exception and a Qt
- function header that displays a message box are
- provided in:
-
- ``KERNEL_SRC/src/SALOMEGUI/SALOMEGUI_QtCatchCorbaException.hxx``
-
- ::
-
- #include "SALOMEGUI_QtCatchCorbaException.hxx"
-
- A typical exchange with a CORBA Servant will be::
-
- try
- {
- ... // one ore more CORBA calls
- }
-
- catch (const SALOME::SALOME_Exception & S_ex)
- {
- QtCatchCorbaException(S_ex);
- }
-
-
-
-CORBA Client, C++, without GUI
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
- Nothing specific has been provided to the developer
- yet. See the idl or the Qt function
- SALOMEGUI_QtCatchCorbaException.hxx to see how to get
- the information given by the exception object.
-
-Miscellaneous tools
-===================
-
-Singleton
----------
-
-Definition
-~~~~~~~~~~
-
-A singleton is an application data which is created and
-deleted only once at the end of the application
-process. The C++ compiler allows the user to create a
-static singleton data before the first executable
-statement. They are deleted after the last statement execution.
-
-The ``SINGLETON_`` template class deals with dynamic
-singleton. It is useful for functor objects. For
-example, an object that connects the application to a
-system at creation and disconnects the application at deletion.
-
-Usage
-~~~~~
-
-To create a single instance of a POINT object::
-
- # include "Utils_SINGLETON.hxx"
- ...
- POINT *ptrPoint=SINGLETON_<POINT>::Instance() ;
- assert(ptrPoint!=NULL) ;
-
-No need to delete ptrPoint. Deletion is achieved
-automatically at exit. If the user tries to create more
-than one singleton by using the class method
-SINGLETON_<TYPE>::Instance(), the pointer is returned
-with the same value even if this is done in different
-functions (threads ?)::
-
- POINT *p1=SINGLETON_<POINT>::Instance() ;
- ...
- POINT *p2=SINGLETON_<POINT>::Instance() ;
-
- assert(p1==p2)
-
-Design description
-~~~~~~~~~~~~~~~~~~
-
-Here are the principles features of the singleton
-design:
-
-* the user creates an object of class TYPE by using the
- class method ``SINGLETON_<TYPE>::Instance()`` which
- returns a pointer to the single object ;
-
-* to create an object, ``SINGLETON_<TYPE>::Instance()``
- uses the default constructor of class TYPE ;
-
-* at the same time, this class method creates a
- destructor object which is added to the generic list
- of destructor objects to be executed at the end of
- the application (atexit) ;
-
-* at the end of the application process all the
- deletions are performed by the ``Nettoyage()`` C function
- which executes the destruction objects end then
- deletes the destructions objects themselves ;
-
-* the ``Nettoyage()`` C function using ``atexit()`` C function
- is embedded in a static single object ``ATEXIT_()``.
-
-
--------------------------------------------------------------------------------
-
-+----------------------------------+------------------------------------------+
-| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ |
-+----------------------------------+------------------------------------------+
-
-.. _`General KERNEL documentation`: ./index.html
-.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html
+++ /dev/null
-/*
-:Authors: David Goodger, David Abrahams
-:Contact: goodger@users.sourceforge.net, dave@boost-consulting.com
-:date: $Date$
-:version: $Revision$
-:copyright: This stylesheet has been placed in the public domain.
-
-This stylesheet is for the use of ReStructuredText in a Boost context.
-It is basically an agglomeration of boost.css and the default.css that
-comes from docutils.
-
- */
-
-.first {
- margin-top: 0 }
-
-.last {
- margin-bottom: 0 }
-
-a.toc-backref {
- text-decoration: none ;
- color: #00008B }
-
-dd {
- margin-bottom: 0.5em }
-
-div.abstract {
- margin: 2em 5em }
-
-div.abstract p.topic-title {
- font-weight: bold ;
- text-align: center }
-
-div.attention, div.caution, div.danger, div.error, div.hint,
-div.important, div.note, div.tip, div.warning, div.admonition {
- margin: 2em ;
- border: medium outset ;
- padding: 1em }
-
-div.attention p.admonition-title, div.caution p.admonition-title,
-div.danger p.admonition-title, div.error p.admonition-title,
-div.warning p.admonition-title {
- color: red ;
- font-weight: bold ;
- font-family: sans-serif }
-
-div.hint p.admonition-title, div.important p.admonition-title,
-div.note p.admonition-title, div.tip p.admonition-title,
-div.admonition p.admonition-title {
- font-weight: bold ;
- font-family: sans-serif }
-
-div.dedication {
- margin: 2em 5em ;
- text-align: center ;
- font-style: italic }
-
-div.dedication p.topic-title {
- font-weight: bold ;
- font-style: normal }
-
-div.figure {
- margin-left: 2em }
-
-div.footer, div.header {
- font-size: smaller }
-
-div.sidebar {
- margin-left: 1em ;
- border: medium outset ;
- padding: 0em 1em ;
- background-color: #ffffee ;
- width: 40% ;
- float: right ;
- clear: right }
-
-div.sidebar p.rubric {
- font-family: sans-serif ;
- font-size: medium }
-
-div.system-messages {
- margin: 5em }
-
-div.system-messages h1 {
- color: red }
-
-div.system-message {
- border: medium outset ;
- padding: 1em }
-
-div.system-message p.system-message-title {
- color: red ;
- font-weight: bold }
-
-div.topic {
- margin: 2em }
-
-H1.title
-{
- FONT-SIZE: 150%;
- COLOR: #00008B;
- text-align: center
-}
-H1
-{
- FONT-SIZE: 125%;
-}
-H2
-{
- FONT-SIZE: 108%;
-}
-h2.subtitle {
- text-align: center }
-H3
-{
- FONT-SIZE: 100%;
-}
-BODY
-{
- FONT-SIZE: 100%;
- BACKGROUND-COLOR: #ffffff;
-}
-PRE
-{
- MARGIN-LEFT: 2em;
- FONT-FAMILY: Courier;
-}
-CODE
-{
- FONT-FAMILY: Courier;
- white-space: pre;
-}
-.pre
-{
- FONT-FAMILY: Courier;
- white-space: pre;
-}
-.index
-{
- TEXT-ALIGN: left;
-}
-.page-index
-{
- TEXT-ALIGN: left;
-}
-.definition
-{
- TEXT-ALIGN: left;
-}
-.footnote
-{
- FONT-SIZE: 66%;
- VERTICAL-ALIGN: super;
- TEXT-DECORATION: none;
-}
-.function-semantics
-{
- CLEAR: left;
-}
-
-hr {
- width: 75% }
-
-ol.simple, ul.simple {
- margin-bottom: 1em }
-
-ol.arabic {
- list-style: decimal }
-
-ol.loweralpha {
- list-style: lower-alpha }
-
-ol.upperalpha {
- list-style: upper-alpha }
-
-ol.lowerroman {
- list-style: lower-roman }
-
-ol.upperroman {
- list-style: upper-roman }
-
-p.attribution {
- text-align: right ;
- margin-left: 50% }
-
-p.caption {
- font-style: italic }
-
-p.credits {
- font-style: italic ;
- font-size: smaller }
-
-p.label {
- white-space: nowrap }
-
-p.rubric {
- font-weight: bold ;
- font-size: larger ;
- color: maroon ;
- text-align: center }
-
-p.sidebar-title {
- font-family: sans-serif ;
- font-weight: bold ;
- font-size: larger }
-
-p.sidebar-subtitle {
- font-family: sans-serif ;
- font-weight: bold }
-
-p.topic-title {
- font-weight: bold }
-
-pre.address {
- margin-bottom: 0 ;
- margin-top: 0 ;
- font-family: serif ;
- font-size: 100% }
-
-pre.line-block {
- font-family: serif ;
- font-size: 100% }
-
-pre.literal-block, pre.doctest-block {
- margin-left: 2em ;
- margin-right: 2em ;
- font-size: 80%;
- border: solid thin gray ;
- background-color: #eeeeee }
-
-span.classifier {
- font-family: sans-serif ;
- font-style: oblique }
-
-span.classifier-delimiter {
- font-family: sans-serif ;
- font-weight: bold }
-
-span.interpreted {
- font-family: sans-serif }
-
-span.option {
- white-space: nowrap }
-
-span.option-argument {
- font-style: italic }
-
-span.pre {
- white-space: pre }
-
-span.problematic {
- color: red }
-
-table {
- margin-top: 0.5em ;
- margin-bottom: 0.5em }
-
-table.citation {
- border-left: solid thin gray ;
- padding-left: 0.5ex }
-
-table.docinfo {
- margin: 2em 4em }
-
-table.footnote {
- border-left: solid thin black ;
- padding-left: 0.5ex }
-
-td, th {
- padding-left: 0.5em ;
- padding-right: 0.5em ;
- vertical-align: top }
-
-th.docinfo-name, th.field-name {
- font-weight: bold ;
- text-align: left ;
- white-space: nowrap }
-
-/*
- dwa 2003/7/29 -- commented out so that it wouldn't override earlier
- styles from boost.css
-
-h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
- font-size: 100% }
-*/
-
-ul.auto-toc {
- list-style-type: none }
--- /dev/null
+/*!
+
+\page kernelpypkg_page Programming Interface of the KERNEL python package
+
+Sorry, but the documentation is not available yet in doxygen format.
+
+Fortunately, a documentation exists in restructured format and then
+can be generated here using sphinx, in the expectative of the doxygen
+version.
+
+Please refer to this <a href="../../tui/KERNEL/docutils/index.html">
+documentation of the KERNEL python packages</a>.
+
+*/
- \subpage kernel_salome
- \subpage dsc_page : DSC documentation page.
- \subpage salome_file_page : Salome_file documentation page.
+ - \subpage kernelpypkg_page : Documentation of the KERNEL python packages
*/
+++ /dev/null
-#!/bin/sh
-# Copyright (C) 2007-2010 CEA/DEN, EDF R&D, OPEN CASCADE
-#
-# Copyright (C) 2003-2007 OPEN CASCADE, EADS/CCR, LIP6, CEA/DEN,
-# CEDRAT, EDF R&D, LEG, PRINCIPIA R&D, BUREAU VERITAS
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-# ===================================================================
-# This shell script is provided for generating the html files
-# from the txt files (restructured text) in the source directory.
-# Usage: just execute the script where it stands in the source
-# directory. The file list has to be updated manually when adding
-# a new restructured text file.
-# Note that the building process executes a target rstdoc that
-# generates the html documentation without need of this script.
-# The autoconficuration (check_htmlgen.m4) set the correct generator
-# rst2html by replacing the @RST2HTML@ tag.
-# ===================================================================
-# (CSSI - gboulant - 25/10/05)
-# This must be updated manually in this script (for source usage only)
-#
-RST2HTML=rst2html
-
-FILELIST="index
- UnitTests
- SALOME_Application
- INSTALL
- kernel_resources
- userguide"
-
-STYLESHEET=rst.css
-RSTOPTS="--output-encoding=latin1 --stylesheet=$STYLESHEET"
-
-for file in $FILELIST; do
- bfn=`basename $file .txt`
- echo "Generating ${bfn}.html from ${bfn}.txt ..."
- $RST2HTML $RSTOPTS ${bfn}.txt ${bfn}.html
-done
-
+++ /dev/null
-=================================================================
-User's guide, for developpers and users
-=================================================================
-
-*html version of this document is produced with docutils*::
-
- rst2html < doc.txt > doc.html
-
-*This document corresponds to SALOME2 3.1.0*
-*NOT UP TO DATE with 3.2.0*
-
-.. contents::
-.. sectnum::
-
-+-------------------------------------------+
-| **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
-+-------------------------------------------+
-
--------------------------------------------------------------------------------
-
-This guide provides you with some basic concepts for developing and
-using the SALOME platform. You will find some information on the
-general technical architecture ...
-
-Introduction
-============
-
-General information
--------------------
-
-This document has been initialized by collecting and updating an existing
-documentation. The restructured text format has been selected for
-writing. This format can be read with a basic editor except for
-pictures and some hypertext links. You can build the html pages using
-the docutils scripts provided with python packages on most platform.
-
-Definitions
------------
-
-``WORK IN PROGRESS``
-
-Module
- definition of a module and/or link to the definition
-
-Container
- definition of a container
-
-
-General concepts
-================
-modules et dépendances (s'inspirer de PYHELLO)
-
-
-Filesystem organisation
-========================
-
-Voir doc de JR "Organisation de la plate-forme"
-
-A typical source working directory
-----------------------------------
-organisation type des sources d'un module standard (spécifications techniques)
-
-A typical installation directory
---------------------------------
-organisation type des produits installés
-
-
-Building process
-================
-Procédures de compilation (renvoie au install.sh)
-
-
-Developer's guide - basic concepts
-=========================================
-
-Guide du développeur: éléments de conception
- - zoom sur certains éléments techniques bons à connaitre pour faire
- évoluer le KERNEL sans tout casser.
- - les ressources du kernel:
- - trace, debug, exception (cf. kernel_ressources.tex)
- - classes batch (présentation puis renvoi à la doc d'Ivan)
- - développement de tests unitaires
-
-Developer's guide - managing the development space
-==================================================
-
-- Guide du développeur: gestion de l'espace de développement
- - principe de mise en oeuvre (rôle des étapes: build_configure, ...)
- - description des fichiers m4 et du principe de mise en oeuvre
- - les Makefile.in, ... (cf. doc guide du développeur).
- - évolution des procédures de construction
- - personalisation des procédures de construction
-
-Developer' guide - integration tools
-====================================
-- Guide de l'intégrateur (développeur de nouveaux modules)
-(on lui montre ici le principe de construction et les ressources à
-disposition pour faire le travail)
- - création d'un modules
- - intégration code boîte noire (perfect, solver)
- - intégration bibliothèque de fonctions (hxx2salome, voir avec
- N.Crouzet)
- - intégration de modèles de données (xdata)
-
-
-End user's guide
-================
-- Guide de l'utilisateur
- - concept d'application (renvoie doc Paul)
- - commandes avancées (showNS, exemple de contact de la
- session, d'un engine, utilisation du lifeCycle, du module salome,
- des modules geompy et smesh)
- - utilisation en mode distribué (doc de B. Sechet)
- - GUI and TUI documentation
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-RST Exemples
-============
-
-See INSTALL_ for general information on required configuration and
-prerequisites, compilation procedure, setting environment principles.
-
-.. _INSTALL: ./INSTALL.html
-
-
--------------------------------------------------------------------------------
-
-+----------------------------------+------------------------------------------+
-| `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ |
-+----------------------------------+------------------------------------------+
-
-.. _`General KERNEL documentation`: ./index.html
-.. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html
check_calcium.m4 \
check_hdf5.m4 \
check_htmlgen.m4 \
+check_sphinx.m4 \
check_lam.m4 \
check_libbatch.m4 \
check_mpi.m4 \
--- /dev/null
+dnl Copyright (C) 2006-2008 CEA/DEN, EDF R&D
+dnl
+dnl This library is free software; you can redistribute it and/or
+dnl modify it under the terms of the GNU Lesser General Public
+dnl License as published by the Free Software Foundation; either
+dnl version 2.1 of the License.
+dnl
+dnl This library is distributed in the hope that it will be useful,
+dnl but WITHOUT ANY WARRANTY; without even the implied warranty of
+dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+dnl Lesser General Public License for more details.
+dnl
+dnl You should have received a copy of the GNU Lesser General Public
+dnl License along with this library; if not, write to the Free Software
+dnl Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+dnl
+dnl See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
+dnl
+AC_DEFUN([CHECK_SPHINX],[
+
+AC_CHECKING(for sphinx doc generator)
+
+sphinx_ok=yes
+dnl where is sphinx ?
+AC_PATH_PROG(SPHINX,sphinx-build)
+if test "x$SPHINX" = "x"
+then
+ AC_MSG_WARN(sphinx not found)
+ sphinx_ok=no
+fi
+
+AM_CONDITIONAL(SPHINX_IS_OK, [test x"$sphinx_ok" = xyes])
+
+])dnl
+dnl
libdir = $(prefix)/lib@LIB_LOCATION_SUFFIX@/salome
bindir = $(prefix)/bin/salome
salomescriptdir = $(bindir)
+# _GBO_SALOME_PYTHON_PACKAGING_
+# Maybe we could try to suppress on stage in this folder path, for
+# example by installing by default the python files in site-packages
+# folder. Then, python packages could be installed in the
+# site-packages/salome folder (main package containing the root
+# __init__.py file). This could be done by replacing salomepythondir
+# and salomepyexecdir by pythondir and pyexecdir respectively (TO BE
+# DONE)
salomepythondir = $(pythondir)/salome
salomepyexecdir = $(pyexecdir)/salome
-
+salomepypkgdir = $(salomepythondir)/salome
# Directory for installing idl files
salomeidldir = $(prefix)/idl/salome
salomepython_PYTHON += \
Help.py \
PyInterp.py \
- salome.py \
batchmode_salome.py \
salome_test.py \
salome_kernel.py \
salome_genericobj.py
endif
+# _GBO_SALOME_PYTHON_PACKAGING_
+# Note that the salome.py should not be installed any more
+# Special extention to create a python packaging
+SUBDIRS= kernel
+salomepypkg_PYTHON= \
+ __init__.py
+
sharedpkgpython_PYTHON = kernel_shared_modules.py
--- /dev/null
+# -*- coding: iso-8859-1 -*-
+# Copyright (C) 2007-2010 CEA/DEN, EDF R&D, OPEN CASCADE
+#
+# Copyright (C) 2003-2007 OPEN CASCADE, EADS/CCR, LIP6, CEA/DEN,
+# CEDRAT, EDF R&D, LEG, PRINCIPIA R&D, BUREAU VERITAS
+#
+# This library is free software; you can redistribute it and/or
+# modify it under the terms of the GNU Lesser General Public
+# License as published by the Free Software Foundation; either
+# version 2.1 of the License.
+#
+# This library is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# Lesser General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public
+# License along with this library; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+#
+# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
+#
+
+# File : salome.py renamed as __init__.py for python packaging (gboulant)
+# Author : Paul RASCLE, EDF
+# Module : SALOME
+# $Header$
+#
+"""
+Module salome gives access to Salome ressources.
+
+variables:
+
+ - salome.orb : CORBA
+ - salome.naming_service : instance of naming Service class
+ - methods:
+ - Resolve(name) : find a CORBA object (ior) by its pathname
+ - Register(name) : register a CORBA object under a pathname
+
+ - salome.lcc : instance of lifeCycleCORBA class
+ - methods:
+ - FindOrLoadComponent(server,name) :
+ obtain an Engine (CORBA object)
+ or launch the Engine if not found,
+ with a Server name and an Engine name
+
+ - salome.sg : salome object to communicate with the graphical user interface (if any)
+ - methods:
+ - updateObjBrowser(bool):
+ - getActiveStudyId():
+ - getActiveStudyName():
+
+ - SelectedCount(): returns number of selected objects
+ - getSelected(i): returns entry of selected object number i
+ - getAllSelected(): returns list of entry of selected objects
+ - AddIObject(Entry): select an existing Interactive object
+ - RemoveIObject(Entry): remove object from selection
+ - ClearIObjects(): clear selection
+
+ - Display(*Entry):
+ - DisplayOnly(Entry):
+ - Erase(Entry):
+ - DisplayAll():
+ - EraseAll():
+
+ - IDToObject(Entry): returns CORBA reference from entry
+
+ - salome.myStudyName : active Study Name
+ - salome.myStudyId : active Study Id
+ - salome.myStudy : the active Study itself (CORBA ior)
+ - methods : defined in SALOMEDS.idl
+
+"""
+## @package salome
+# Module salome gives access to Salome ressources.
+#
+# \param salome.orb : CORBA orb object
+# \param salome.naming_service : instance of naming Service class (SALOME_NamingServicePy::SALOME_NamingServicePy_i)
+# \param salome.lcc : instance of lifeCycleCORBA class (SALOME_LifeCycleCORBA)
+# \param salome.sg : Salome object to communicate with the graphical user interface, if running (see interface in salome_iapp::SalomeOutsideGUI)
+# \param salome.myStudyName : active Study Name
+# \param salome.myStudyId : active Study Id
+# \param salome.myStudy : the active Study (interface SALOMEDS::Study)
+
+#
+# ==========================================================================
+print "INFO - You just load the python package salome, replacing the python module salome.py"
+#
+# The function extend_path is used here to aggregate in a single
+# virtual python package all the python sub-packages embedded in each
+# SALOME modules (python "namespace" pattern).
+#
+ROOT_PYTHONPACKAGE_NAME="salome"
+#
+# This root package name is expected to be found as a directory in
+# some paths of the sys.path variable, especially the paths
+# <MODULE_ROOT_DIR>/lib/pythonX.Y/site-packages/salome where are
+# installed the python files. These paths are theorically appended by
+# the SALOME main runner and should be in the sys.path at this point
+# of the application. The extend_path is looking then for directories
+# of the type:
+#
+# <MODULE_ROOT_DIR>/lib/pythonX.Y/site-packages/salome/<ROOT_PYTHONPACKAGE_NAME>
+#
+# And append them to the sys.path. These directories are supposed to
+# be the pieces to be aggregated as a single virtual python package.
+#
+import os, sys
+MATCH_ENDING_PATTERN="site-packages/salome"
+def extend_path(pname):
+ for dir in sys.path:
+ if not isinstance(dir, basestring) or not os.path.isdir(dir) or not dir.endswith(MATCH_ENDING_PATTERN):
+ continue
+ subdir = os.path.join(dir, pname)
+ # XXX This may still add duplicate entries to path on
+ # case-insensitive filesystems
+ if os.path.isdir(subdir) and subdir not in __path__:
+ print "INFO - The directory %s is appended to sys.path" % subdir
+ __path__.append(subdir)
+
+extend_path(ROOT_PYTHONPACKAGE_NAME)
+# ==========================================================================
+#
+
+from salome_kernel import *
+from salome_study import *
+from salome_iapp import *
+
+#
+# The next block is workaround for the problem of shared symbols loading for the extension modules (e.g. SWIG-generated)
+# that causes RTTI unavailable in some cases. To solve this problem, sys.setdlopenflags() function is used.
+# Depending on the Python version and platform, the dlopen flags can be defined in the dl, DLFUN or ctypes module.
+#
+import sys
+flags = None
+if not flags:
+ try:
+ # dl module can be unavailable
+ import dl
+ flags = dl.RTLD_NOW | dl.RTLD_GLOBAL
+ except:
+ pass
+ pass
+if not flags:
+ try:
+ # DLFCN module can be unavailable
+ import DLFCN
+ flags = DLFCN.RTLD_NOW | DLFCN.RTLD_GLOBAL
+ except:
+ pass
+ pass
+if not flags:
+ try:
+ # ctypes module can be unavailable
+ import ctypes
+ flags = ctypes.RTLD_GLOBAL
+ except:
+ pass
+ pass
+
+if flags:
+ sys.setdlopenflags(flags)
+ pass
+
+orb, lcc, naming_service, cm,sg=None,None,None,None,None
+myStudyManager, myStudyId, myStudy, myStudyName=None,None,None,None
+
+salome_initial=1
+def salome_init(theStudyId=0,embedded=0):
+ """
+ Performs only once SALOME general purpose intialisation for scripts.
+ optional argument : theStudyId
+ When in embedded interpreter inside IAPP, theStudyId is not used
+ When used without GUI (external interpreter)
+ 0 : create a new study (default).
+ n (>0) : try connection to study with Id = n, or create a new one
+ if study not found.
+ If study creation, its Id may be different from theStudyId !
+ Provides:
+ orb reference to CORBA
+ lcc a LifeCycleCorba instance
+ naming_service a naming service instance
+ cm reference to the container manager
+ sg access to SALOME GUI (when linked with IAPP GUI)
+ myStudyManager the study manager
+ myStudyId active study identifier
+ myStudy active study itself (CORBA reference)
+ myStudyName active study name
+ """
+ global salome_initial
+ global orb, lcc, naming_service, cm
+ global sg
+ global myStudyManager, myStudyId, myStudy, myStudyName
+
+ try:
+ if salome_initial:
+ salome_initial=0
+ sg = salome_iapp_init(embedded)
+ orb, lcc, naming_service, cm = salome_kernel_init()
+ myStudyManager, myStudyId, myStudy, myStudyName =salome_study_init(theStudyId)
+ pass
+ pass
+ except RuntimeError, inst:
+ # wait a little to avoid trace mix
+ import time
+ time.sleep(0.2)
+ x = inst
+ print "salome.salome_init():", x
+ print """
+ ============================================
+ May be there is no running SALOME session
+ salome.salome_init() is intented to be used
+ within an already running session
+ ============================================
+ """
+ raise
+
+#to expose all objects to pydoc
+__all__=dir()
--- /dev/null
+include $(top_srcdir)/salome_adm/unix/make_common_starter.am
+
+mypkgpythondir =$(salomepypkgdir)/kernel
+
+mypkgpython_PYTHON = \
+ __init__.py \
+ deprecation.py \
+ logger.py \
+ studyedit.py \
+ termcolor.py \
+ logconfig.py
--- /dev/null
+# -*- coding: iso-8859-1 -*-
+__all__ = [ "deprecation", "logger", "termcolor", "studyedit", "logconfig" ]
--- /dev/null
+# -*- coding: utf-8 -*-
+#
+# Copyright (C) 2007-2009 EDF R&D
+#
+# This file is part of PAL_SRC.
+#
+# PAL_SRC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# PAL_SRC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with PAL_SRC; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+#
+"""
+This module provides several functions to indicate the deprecation of a
+module, a method or a function. This is a temporary module to be used only
+during PAL refactoring.
+"""
+
+import sys
+import warnings
+import inspect
+import os
+
+from salome.kernel import termcolor
+
+msg_seedoc = "See PAL refactoring documentation for possible replacements."
+
+def __deprecated_with_msg(func, msg):
+
+ def new_func(*args, **kwargs):
+ if len(inspect.stack()) > 1:
+ callingfunc = inspect.stack()[1][3]
+ else:
+ callingfunc = "CORBA middleware"
+ warnings.warn(
+ ("Call to deprecated function %(funcname)s of module " +
+ "%(modname)s (called from %(callingfunc)s).\n %(msg)s") % {
+ 'funcname': func.__name__,
+ 'modname': func.__module__,
+ 'callingfunc': callingfunc,
+ 'msg': msg,
+ },
+ category = DeprecationWarning,
+ stacklevel = 2
+ )
+ return func(*args, **kwargs)
+ return new_func
+
+def deprecated(msg = msg_seedoc):
+ """
+ This is a decorator which can be used to mark functions
+ as deprecated. It will result in a warning being emitted
+ when the function is used. The message in parameter will
+ be displayed and should indicate how this function can be
+ replaced. If the terminal can display colors, the warning
+ messages will appear in blue.
+ """
+ def make_dep(f):
+ if is_called_by_sphinx():
+ return f
+ else:
+ g = __deprecated_with_msg(f, msg)
+ g.__name__ = f.__name__
+ g.__doc__ = f.__doc__
+ g.__dict__.update(f.__dict__)
+ return g
+ return make_dep
+
+def deprecated_module(msg = msg_seedoc):
+ """
+ This function can be used to mark a module as deprecated.
+ It must be called explicitly at the beginning of the deprecated
+ module. It will result in a warning being emitted. The message
+ in parameter will be displayed and should indicate how this
+ module can be replaced. If the terminal can display colors,
+ the warning messages will appear in blue.
+ """
+ if not is_called_by_sphinx():
+ warnings.warn(
+ "Importation of deprecated module %(modname)s.\n %(msg)s" % {
+ 'modname': inspect.getmodulename(inspect.stack()[1][1]),
+ 'msg': msg,
+ },
+ category = DeprecationWarning,
+ stacklevel = 5
+ )
+
+def is_called_by_sphinx():
+ """
+ Determine if the calling code is ultimately called by sphinx to generate
+ documentation. The result can be used to conditionally inhibit the
+ decorators or some Salome-related imports that fail when called outside
+ Salome.
+ """
+ calling_file = inspect.stack()[len(inspect.stack())-1][1]
+ basename = os.path.basename(calling_file)
+ return (basename == "sphinx-build")
+
+
+def __show_colored_warning(message, category, filename,
+ lineno, file = sys.stderr):
+ str = warnings.formatwarning(message, category, filename, lineno)
+ if category == DeprecationWarning and termcolor.canDisplayColor(file):
+ file.write(termcolor.makeColoredMessage(str, termcolor.BLUE))
+ else:
+ file.write(str)
+
+warnings.showwarning = __show_colored_warning
--- /dev/null
+# -*- coding: utf-8 -*-
+#
+# Copyright (C) 2007-2009 EDF R&D
+#
+# This file is part of PAL_SRC.
+#
+# PAL_SRC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# PAL_SRC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with PAL_SRC; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+#
+"""
+This module defines a variable to indicate which traces should be logged.
+"""
+
+import logging
+
+loggingLevel = logging.@PYLOGLEVEL@
--- /dev/null
+# -*- coding: utf-8 -*-
+#
+# Copyright (C) 2007-2009 EDF R&D
+#
+# This file is part of PAL_SRC.
+#
+# PAL_SRC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# PAL_SRC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with PAL_SRC; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+#
+
+#=============================================================================
+# Author : Guillaume Boulant (CSSI)
+# Rewritten by Renaud Barate (EDF R&D)
+# Project : SALOME
+# Copyright : EDF 2001-2009
+# $Header$
+#=============================================================================
+"""
+This module defines a class which provides logging facility in Salome:
+"""
+
+import sys, os
+import logging
+
+from salome.kernel import termcolor
+import salome.kernel.logconfig
+
+class Logger(logging.Logger):
+ """
+ This class formats and displays log messages in Salome environment. It
+ inherits :class:`Logger<logging.Logger>` class defined in :mod:`logging`
+ module from Python library, so all methods from :class:`logging.Logger`
+ can be used here. The format of the traces is:
+
+ LEVEL [keyword] : Message
+
+ where `LEVEL` is the level of the message (`DEBUG`, `INFO`, etc.),
+ `keyword` is the name of the logger, and `Message` is the message to log.
+
+ When creating a new Logger object, the parameter `keyword` defines the
+ name of the logger, `level` defines the logging level (default is
+ :const:`logging.WARNING` if PAL module is configured with --disable-debug
+ option or :const:`logging.DEBUG` otherwise), and `color` defines the color
+ of the log messages for this logger (log messages will appear in color
+ only when displayed on color-capable ASCII terminals). See module
+ :mod:`salome.kernel.termcolor` for the color constants.
+
+ By default, log messages will be displayed only on standard output. They
+ can also be recorded in a file (see method :meth:`setLogFile`). For now,
+ the CORBA-based logging facility can not be used through this class.
+
+ A source filename `sourceFileName` can be defined. If this argument is
+ specified, then the `keyword` is modified to the basename of the `sourceFileName`
+
+ Basic usage::
+
+ from salome.kernel.logger import Logger
+ log = Logger("Test")
+ log.debug("Debug message")
+ log.info("Information message")
+ log.warning("Warning message")
+ log.error("Error message")
+ log.critical("Fatal error message")
+
+ """
+
+ def __init__(self, keyword = "KEY", level = salome.kernel.logconfig.loggingLevel,
+ color = None, sourceFileName=None):
+
+ if sourceFileName is not None:
+ keyword = os.path.basename(sourceFileName).split('.')[0]
+ logging.Logger.__init__(self, keyword, level)
+ self._baseFormatString = "%(levelname)-8s [%(name)s] : %(message)s"
+ self._baseFormatter = logging.Formatter(self._baseFormatString)
+ if hasattr(sys.stdout, "flush"):
+ self._stdoutStream = sys.stdout
+ else:
+ self._stdoutStream = _UnFlushableLogStream(sys.stdout)
+ self._stdoutHandler = logging.StreamHandler(self._stdoutStream)
+ self._stdoutHandler.setLevel(logging.DEBUG)
+ self.setColor(color)
+ self.addHandler(self._stdoutHandler)
+ self._fileHandler = None
+
+ def showDebug(self):
+ """
+ Log all messages, including DEBUG level messages (equivalent to
+ ``setLevel(logging.DEBUG)``).
+ """
+ self.setLevel(logging.DEBUG)
+
+ def setLogFile(self, logFilename):
+ """
+ Define a log file to record the log messages (in addition to the
+ standard output).
+ """
+ self.closeLogFile()
+ self._fileHandler = logging.FileHandler(logFilename, 'w')
+ self._fileHandler.setLevel(logging.DEBUG)
+ self._fileHandler.setFormatter(self._baseFormatter)
+ self.addHandler(self._fileHandler)
+
+ def setColor(self, color):
+ """
+ Set the color of log messages on color-capable terminals. If `color`
+ is :const:`None`, the default color will be used.
+ """
+ if color is None or not termcolor.canDisplayColor(self._stdoutStream):
+ stdoutFormatter = self._baseFormatter
+ else:
+ format = ("%s%s%s" %
+ (termcolor.getControlSequence(color),
+ self._baseFormatString,
+ termcolor.getControlSequence(termcolor.DEFAULT)))
+ stdoutFormatter = logging.Formatter(format)
+ self._stdoutHandler.setFormatter(stdoutFormatter)
+
+ def closeLogFile(self):
+ """Close the log file."""
+ if self._fileHandler is not None:
+ self.removeHandler(self._fileHandler)
+ self._fileHandler.close()
+ self._fileHandler = None
+
+ def hideDebug(self):
+ """
+ Hide DEBUG level messages (equivalent to ``setLevel(logging.INFO)``).
+ """
+ self.setLevel(logging.INFO)
+
+ def fatal(self, message):
+ """
+ Log a message with CRITICAL level. This method only exists for
+ backward compatibility and is equivalent to ``critical(message)``.
+ """
+ self.critical(message)
+
+
+class _UnFlushableLogStream:
+ """
+ This utility class allows to log messages to a stream with no `flush`
+ method. This is useful to send log messages to `PyOut` objects.
+ """
+
+ def __init__(self, stream):
+ self._stream = stream
+
+ def write(self, msg):
+ self._stream.write(msg)
+
+ def flush(self):
+ pass
+
+
+class ExtLogger(Logger):
+ """
+ This class extends :class:`Logger` class and adds exception information
+ when DEBUG messages are recorded. It exists mainly for backward
+ compatibility, as the same thing can be done by calling
+ ``Logger.debug(message, exc_info = True)``.
+ """
+
+ def debug( self, message ):
+ """
+ Log a DEBUG message with exception information (equivalent to
+ ``Logger.debug(message, exc_info = True)``).
+ """
+ Logger.debug(self, message, exc_info = True)
+
+
+def TEST_Logger():
+ """Test function for logger module"""
+ log = Logger("TST")
+
+ # Base methods
+ log.info("Information message")
+ log.debug("Debug message")
+ log.fatal("Fatal error message")
+
+ # Message building
+ data = 12
+ log.info("This message displays data = " + str(data))
+
+ data = {}
+ data["KERNEL"] = "V1"
+ data["GEOM"] = "V2"
+ log.info("This message displays data = " + str(data))
+
+ # Test with a non-string parameter
+ log.info(data)
+
+ # Test with a default instance
+ log = Logger()
+ log.info("Default logger")
+
+ # Test showDebug method
+ log.setLogFile("test.log")
+ log.debug("Debug trace")
+ log.hideDebug()
+ log.debug("This trace should NOT be displayed")
+ log.showDebug()
+ log.debug("This trace should be displayed")
+ log.closeLogFile()
+ log.info("After closing the log file")
+
+
+# Main function only used to test the module
+if __name__ == "__main__":
+ TEST_Logger()
--- /dev/null
+# -*- coding: utf-8 -*-
+#
+# Copyright (C) 2007-2009 EDF R&D
+#
+# This file is part of PAL_SRC.
+#
+# PAL_SRC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# PAL_SRC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with PAL_SRC; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+#
+"""
+This module provides a new class :class:`StudyEditor` to complement
+:class:`Study` and :class:`StudyBuilder` classes.
+"""
+
+import re
+
+import salome
+from salome.kernel.logger import Logger
+from salome.kernel import termcolor
+logger = Logger("salome.kernel.studyedit", color = termcolor.PURPLE)
+
+_editors = {}
+_DEFAULT_CONTAINER = "FactoryServer"
+
+def getActiveStudyId():
+ """
+ Return the ID of the active study. In GUI mode, this function is equivalent
+ to ``salome.sg.getActiveStudyId()``. Outside GUI, it returns
+ ``salome.myStudyId`` variable.
+ """
+ salome.salome_init()
+ if salome.hasDesktop():
+ return salome.sg.getActiveStudyId()
+ else:
+ return salome.myStudyId
+
+def getStudyEditor(studyId = None):
+ """
+ Return a :class:`StudyEditor` instance to edit the study with ID
+ `studyId`. If `studyId` is :const:`None`, return an editor for the current
+ study.
+ """
+ if studyId is None:
+ studyId = getActiveStudyId()
+ if not _editors.has_key(studyId):
+ _editors[studyId] = StudyEditor(studyId)
+ return _editors[studyId]
+
+
+class StudyEditor:
+ """
+ This class provides utility methods to complement :class:`Study` and
+ :class:`StudyBuilder` classes. Those methods may be moved in those classes
+ in the future. The parameter `studyId` defines the ID of the study to
+ edit. If it is :const:`None`, the edited study will be the current study.
+ The preferred way to get a StudyEditor object is through the method
+ :meth:`getStudyEditor` which allows to reuse existing instances.
+
+ .. attribute:: studyId
+
+ This instance attribute contains the ID of the edited study. This
+ attribute should not be modified.
+
+ .. attribute:: study
+
+ This instance attribute contains the underlying :class:`Study` object.
+ It can be used to access the study but the attribute itself should not
+ be modified.
+
+ .. attribute:: builder
+
+ This instance attribute contains the underlying :class:`StudyBuilder`
+ object. It can be used to edit the study but the attribute itself
+ should not be modified.
+
+ """
+ def __init__(self, studyId = None):
+ salome.salome_init()
+ if studyId is None:
+ studyId = getActiveStudyId()
+ self.studyId = studyId
+ self.study = salome.myStudyManager.GetStudyByID(studyId)
+ if self.study is None:
+ raise Exception("Can't create StudyEditor object: "
+ "Study %d doesn't exist" % studyId)
+ self.builder = self.study.NewBuilder()
+
+ def findOrCreateComponent(self, componentName, componentLabel=None, icon=None,
+ loadEngine = True, engineName = None,
+ containerName = _DEFAULT_CONTAINER):
+ """
+ Find a component corresponding to the specified name `componentName` in the
+ study, or create it if none is found. Then eventually load the
+ corresponding engine and the CORBA objects of this component.
+
+ :type componentName: string
+ :param componentName: name of the new component if created. The name is
+ a string used to identify the study component.
+ Generally, it corresponds to the name of the SALOME
+ module to be associated to this component.
+
+ :type componentLabel: string
+ :param componentLabel: label of the new component if created. The label
+ is the string used in the object browser.
+ (attribute "AttributeName")
+
+ :type icon: string
+ :param icon: icon for the new component (attribute "AttributePixMap").
+
+ :type loadEngine: boolean
+ :param loadEngine: If :const:`True`, find or load the corresponding
+ engine and associate it with the component. Default
+ is True.
+
+ :type engineName: string
+ :param engineName: name of the engine to be associated to the component.
+ If :const:`None`, use `componentName` instead because
+ in most of the SALOME modules, the names are identical.
+
+ :type containerName: string
+ :param containerName: name of the container in which the engine should be
+ loaded.
+
+ :return: the SComponent found or created.
+
+ """
+ sComponent = self.study.FindComponent(componentName)
+ if sComponent is None:
+ sComponent = self.builder.NewComponent(componentName)
+ # Note that the NewComponent method set the "comment" attribute to the
+ # value of its argument (componentName here)
+ self.builder.SetName(sComponent, componentLabel)
+ if icon is not None:
+ # _MEM_ : This will be effective if and only if the componentName
+ # corresponds to the module name (as specified in the SalomeApp.xml)
+ self.setIcon(sComponent, icon)
+
+ if engineName is None:
+ engineName = componentName
+
+ engine = salome.lcc.FindOrLoadComponent(containerName,engineName)
+ self.builder.DefineComponentInstance(sComponent, engine)
+
+ # An internal convention (in this class) is to store the name of the
+ # associated engine in the parameter attribute of the scomponent (so that
+ # it could be retrieved in a future usage of this scomponent, for example,
+ # for the need of the function loadComponentEngine). The comment attribute
+ # SHOULD NOT be used for this purpose because it's used by the SALOME
+ # resources manager to identify the SALOME module and then localized
+ # the resource files
+ attr = self.builder.FindOrCreateAttribute( sComponent, "AttributeParameter" )
+ attr.SetString( "ENGINE_NAME", engineName )
+
+ if loadEngine:
+ self.loadComponentEngine(sComponent, containerName)
+
+ return sComponent
+
+ def loadComponentEngine(self, sComponent,
+ containerName = _DEFAULT_CONTAINER):
+ """
+ Load the engine corresponding to `sComponent` in the container
+ `containerName`, associate the engine with the component and load the
+ CORBA objects of this component in the study.
+ """
+ attr = self.builder.FindOrCreateAttribute( sComponent, "AttributeParameter" )
+ engineName = attr.GetString( "ENGINE_NAME" )
+ engine = salome.lcc.FindOrLoadComponent(containerName,
+ engineName)
+ self.builder.LoadWith(sComponent, engine)
+
+ def getOrLoadObject(self, item):
+ """
+ Get the CORBA object associated with the SObject `item`, eventually by
+ first loading it with the corresponding engine.
+ """
+ object = item.GetObject()
+ if object is None: # the engine has not been loaded yet
+ sComponent = item.GetFatherComponent()
+ self.loadComponentEngine(sComponent)
+ object = item.GetObject()
+ return object
+
+ def findOrCreateItem(self, fatherItem, name, fileType = None,
+ fileName = None, comment = None, icon = None,
+ IOR = None, typeId = None):
+ """
+ Find an object under `fatherItem` in the study with the given
+ attributes. Return the first one found if at least one exists,
+ otherwise create a new one with the given attributes and return it.
+
+ See :meth:`setItem` for the description of the parameters.
+ """
+ sObject = self.findItem(fatherItem, name, fileType, fileName, comment,
+ icon, IOR, typeId)
+ if sObject is None:
+ sObject = self.createItem(fatherItem, name, fileType, fileName,
+ comment, icon, IOR, typeId)
+ return sObject
+
+ def findItem(self, fatherItem, name = None, fileType = None,
+ fileName = None, comment = None, icon = None, IOR = None,
+ typeId = None):
+ """
+ Find an item with given attributes under `fatherItem` in the study. If
+ none is found, return :const:`None`. If several items correspond to
+ the parameters, only the first one is returned. The search is made
+ only on given parameters (i.e. not :const:`None`). To look explicitly
+ for an empty attribute, use an empty string in the corresponding
+ parameter.
+
+ See :meth:`setItem` for the description of the parameters.
+ """
+ foundItem = None;
+ childIterator = self.study.NewChildIterator(fatherItem)
+ while childIterator.More() and foundItem is None:
+ childItem = childIterator.Value()
+ if childItem and \
+ (name is None or childItem.GetName() == name) and \
+ (fileType is None or \
+ self.getFileType(childItem) == fileType) and \
+ (fileName is None or \
+ self.getFileName(childItem) == fileName) and \
+ (comment is None or childItem.GetComment() == comment) and \
+ (icon is None or \
+ self.getIcon(childItem) == icon) and \
+ (IOR is None or childItem.GetIOR() == IOR and \
+ (typeId is None or \
+ self.getTypeId(childItem) == typeId)):
+ foundItem = childItem
+ childIterator.Next()
+ return foundItem
+
+ def createItem(self, fatherItem, name, fileType = None, fileName = None,
+ comment = None, icon = None, IOR = None, typeId = None):
+ """
+ Create a new object named `name` under `fatherItem` in the study, with
+ the given attributes. If an object named `name` already exists under
+ the father object, the new object is created with a new name `name_X`
+ where X is the first available index.
+
+ :type fatherItem: SObject
+ :param fatherItem: item under which the new item will be added.
+
+ :return: new SObject created in the study
+
+ See :meth:`setItem` for the description of the other parameters.
+ """
+ aSObject = self.builder.NewObject(fatherItem)
+
+ aChildIterator = self.study.NewChildIterator(fatherItem)
+ aMaxId = -1
+ aLength = len(name)
+ aDelim = "_"
+ anIdRE = re.compile("^" + aDelim + "[0-9]+")
+ aNameRE = re.compile("^" + name)
+ while aChildIterator.More():
+ aSObj = aChildIterator.Value()
+ aChildIterator.Next()
+ aName = aSObj.GetName()
+ if re.match(aNameRE,aName):
+ aTmp = aName[aLength:]
+ if re.match(anIdRE,aTmp):
+ import string
+ anId = string.atol(aTmp[1:])
+ if aMaxId < anId:
+ aMaxId = anId
+ pass
+ pass
+ elif aMaxId < 0:
+ aMaxId = 0
+ pass
+ pass
+ pass
+
+ aMaxId = aMaxId + 1
+ aName = name
+ if aMaxId > 0:
+ aName = aName + aDelim + str(aMaxId)
+ pass
+
+ self.setItem(aSObject, aName, fileType, fileName, comment, icon,
+ IOR, typeId)
+
+ return aSObject
+
+ def setItem(self, item, name = None, fileType = None, fileName = None,
+ comment = None, icon = None, IOR = None, typeId = None):
+ """
+ Modify the attributes of an item in the study. Unspecified attributes
+ (i.e. those set to :const:`None`) are left unchanged.
+
+ :type item: SObject
+ :param item: item to modify.
+
+ :type name: string
+ :param name: item name (attribute 'AttributeName').
+
+ :type fileType: string
+ :param fileType: item file type (attribute 'AttributeFileType').
+
+ :type fileName: string
+ :param fileName: item file name (attribute
+ 'AttributeExternalFileDef').
+
+ :type comment: string
+ :param comment: item comment (attribute 'AttributeComment'). Note that
+ this attribute will appear in the 'Value' column in
+ the object browser.
+
+ :type icon: string
+ :param icon: item icon name (attribute 'AttributePixMap').
+
+ :type IOR: string
+ :param IOR: IOR of a CORBA object associated with the item
+ (attribute 'AttributeIOR').
+
+ :type typeId: integer
+ :param typeId: item type (attribute 'AttributeLocalID').
+ """
+ logger.debug("setItem (ID=%s): name=%s, fileType=%s, fileName=%s, "
+ "comment=%s, icon=%s, IOR=%s" %
+ (item.GetID(), name, fileType, fileName, comment,
+ icon, IOR))
+ # Explicit cast is necessary for unicode to string conversion
+ if name is not None:
+ self.builder.SetName(item, str(name))
+ if fileType is not None:
+ self.setFileType(item, fileType)
+ if fileName is not None:
+ self.setFileName(item, fileName)
+ if comment is not None:
+ self.builder.SetComment(item, str(comment))
+ if icon is not None:
+ self.setIcon(item, icon)
+ if IOR is not None:
+ self.builder.SetIOR(item, str(IOR))
+ if typeId is not None:
+ self.setTypeId(item, typeId)
+
+ def removeItem(self, item, withChildren = False ):
+ """
+ Remove the given item from the study (the item still is in
+ the study after the removal)
+ @param item: the browser object to be removed
+ @param withChildren: remove children if True
+ """
+ ok = False
+ try:
+ if withChildren:
+ self.builder.RemoveObjectWithChildren(item)
+ else:
+ self.builder.RemoveObject(item)
+ ok = True
+ except:
+ ok = False
+
+ return ok
+
+ def setItemAtTag(self, fatherItem, tag, name = None, fileType = None,
+ fileName = None, comment = None, icon = None, IOR = None,
+ typeId = None):
+ """
+ Find an item tagged `tag` under `fatherItem` in the study tree or
+ create it if there is none, then set its attributes.
+
+ :type fatherItem: SObject
+ :param fatherItem: item under which the tagged item will be looked for
+ and eventually created.
+
+ :type tag: integer
+ :param tag: tag of the item to look for.
+
+ :return: the SObject at `tag` if found or created successfully, or
+ :const:`None` if an error happened.
+
+ See :meth:`setItem` for the description of the other parameters.
+ """
+ found, sObj = fatherItem.FindSubObject(tag)
+ if not found:
+ sObj = self.builder.NewObjectToTag(fatherItem, tag)
+ self.setItem(sObj, name, fileType, fileName, comment, icon,
+ IOR, typeId)
+ return sObj
+
+ def getAttributeValue(self, sObject, attributeName, default = None):
+ """
+ Return the value of the attribute named `attributeName` on the object
+ `sObject`, or `default` if the attribute doesn't exist.
+ """
+ value = default
+ found, attr = self.builder.FindAttribute(sObject, attributeName)
+ if found:
+ value = attr.Value()
+ return value
+
+ def setAttributeValue(self, sObject, attributeName, attributeValue):
+ """
+ Set the value of the attribute named `attributeName` on the object
+ `sObject` to the value `attributeValue`.
+ """
+ attr = self.builder.FindOrCreateAttribute(sObject, attributeName)
+ attr.SetValue(attributeValue)
+
+ def getTypeId(self, sObject):
+ """
+ Return the value of the attribute "AttributeLocalID" of the object
+ `sObject`, or :const:`None` if it is not set.
+ """
+ return self.getAttributeValue(sObject, "AttributeLocalID")
+
+ def setTypeId(self, sObject, value):
+ """
+ Set the attribute "AttributeLocalID" of the object `sObject` to the
+ value `value`.
+ """
+ self.setAttributeValue(sObject, "AttributeLocalID", value)
+
+ def getFileType(self, sObject):
+ """
+ Return the value of the attribute "AttributeFileType" of the object
+ `sObject`, or an empty string if it is not set.
+ """
+ return self.getAttributeValue(sObject, "AttributeFileType", "")
+
+ def setFileType(self, sObject, value):
+ """
+ Set the attribute "AttributeFileType" of the object `sObject` to the
+ value `value`.
+ """
+ # Explicit cast is necessary for unicode to string conversion
+ self.setAttributeValue(sObject, "AttributeFileType", str(value))
+
+ def getFileName(self, sObject):
+ """
+ Return the value of the attribute "AttributeExternalFileDef" of the
+ object `sObject`, or an empty string if it is not set.
+ """
+ return self.getAttributeValue(sObject, "AttributeExternalFileDef", "")
+
+ def setFileName(self, sObject, value):
+ """
+ Set the attribute "AttributeExternalFileDef" of the object `sObject`
+ to the value `value`.
+ """
+ # Explicit cast is necessary for unicode to string conversion
+ self.setAttributeValue(sObject, "AttributeExternalFileDef",
+ str(value))
+
+ def getIcon(self, sObject):
+ """
+ Return the value of the attribute "AttributePixMap" of the object
+ `sObject`, or an empty string if it is not set.
+ """
+ value = ""
+ found, attr = self.builder.FindAttribute(sObject, "AttributePixMap")
+ if found and attr.HasPixMap():
+ value = attr.GetPixMap()
+ return value
+
+ def setIcon(self, sObject, value):
+ """
+ Set the attribute "AttributePixMap" of the object `sObject` to the
+ value `value`.
+ """
+ attr = self.builder.FindOrCreateAttribute(sObject, "AttributePixMap")
+ # Explicit cast is necessary for unicode to string conversion
+ attr.SetPixMap(str(value))
--- /dev/null
+# -*- coding: utf-8 -*-
+#
+# Copyright (C) 2007-2009 EDF R&D
+#
+# This file is part of PAL_SRC.
+#
+# PAL_SRC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# PAL_SRC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with PAL_SRC; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+#
+# Author : Renaud Barate (EDF R&D)
+# Date : August 2009
+#
+"""
+This module provides utility functions to display colored text in the
+terminal. It is based on ISO 6429 standard that defines control codes to
+change characters representation in color-capable ASCII terminals.
+
+In this module, colors are represented as lists of codes, so they can be added
+to obtain special effects (e.g. RED + GREEN_BG to display red text on green
+background). Several constants are defined for the most usual codes to
+facilitate the use of colors, but it is also possible to define colors
+directly from the corresponding code from ISO 6429 standard. In fact it is
+even necessary for less usual codes that don't have an associated constant
+(e.g. PURPLE + ['09'] can be used to display a crossed-out purple text).
+
+Example::
+
+ import sys
+ from pal import termcolor
+ if termcolor.canDisplayColor(sys.stdout):
+ print termcolor.makeColoredMessage("Hello world!", termcolor.BLUE)
+ else:
+ print "Hello world!"
+
+"""
+
+# Constants for color codes
+DEFAULT = ['00']
+"""Default color for the terminal"""
+BOLD = ['01']
+"""Bold text and brighter colors"""
+UNDERLINED = ['04']
+"""Underlined text"""
+BLACK_FG = ['30']
+"""Black foreground"""
+RED_FG = ['31']
+"""Red foreground"""
+GREEN_FG = ['32']
+"""Green foreground"""
+YELLOW_FG = ['33']
+"""Yellow foreground"""
+BLUE_FG = ['34']
+"""Blue foreground"""
+PURPLE_FG = ['35']
+"""Purple foreground"""
+CYAN_FG = ['36']
+"""Cyan foreground"""
+WHITE_FG = ['37']
+"""White foreground"""
+BLACK_BG = ['40']
+"""Black background"""
+RED_BG = ['41']
+"""Red background"""
+GREEN_BG = ['42']
+"""Green background"""
+YELLOW_BG = ['43']
+"""Yellow background"""
+BLUE_BG = ['44']
+"""Blue background"""
+PURPLE_BG = ['45']
+"""Purple background"""
+CYAN_BG = ['46']
+"""Cyan background"""
+WHITE_BG = ['47']
+"""White background"""
+
+# Constants for common colored text
+BLACK = BLACK_FG
+"""Black text (equivalent to BLACK_FG)"""
+RED = BOLD + RED_FG
+"""Red text (equivalent to BOLD + RED_FG)"""
+GREEN = BOLD + GREEN_FG
+"""Green text (equivalent to BOLD + GREEN_FG)"""
+YELLOW = BOLD + YELLOW_FG
+"""Yellow text (equivalent to BOLD + YELLOW_FG)"""
+BLUE = BOLD + BLUE_FG
+"""Blue text (equivalent to BOLD + BLUE_FG)"""
+PURPLE = BOLD + PURPLE_FG
+"""Purple text (equivalent to BOLD + PURPLE_FG)"""
+CYAN = BOLD + CYAN_FG
+"""Cyan text (equivalent to BOLD + CYAN_FG)"""
+WHITE = WHITE_FG
+"""White text (equivalent to WHITE_FG)"""
+
+
+def canDisplayColor(stream):
+ """
+ Return True if the stream can display colored text, False otherwise.
+ """
+ return hasattr(stream, "isatty") and stream.isatty()
+
+def getControlSequence(color):
+ """
+ Return the control sequence for the color in parameter, i.e. the string
+ telling the terminal to display the following text in the given color.
+ """
+ seq = "\x1b["
+ for i in range(len(color)):
+ seq += color[i]
+ if i < len(color)-1:
+ seq += ";"
+ seq += "m"
+ return seq
+
+def makeColoredMessage(message, color):
+ """
+ Return a string that can be used to display the message in parameter with
+ the given color.
+ """
+ return (getControlSequence(color) +
+ str(message) +
+ getControlSequence(DEFAULT))
+
+def TEST_termcolor():
+ """Test function for termcolor module."""
+ import sys
+ if not canDisplayColor(sys.stdout):
+ print "Standard output does not support colors."
+ return
+ print makeColoredMessage("This message must appear in blue.", BLUE)
+ print makeColoredMessage("This message must appear in red on green " +
+ "background.", RED + GREEN_BG)
+ print makeColoredMessage("This message must appear in magenta and " +
+ "crossed-out.", PURPLE + ['09'])
+
+
+# Main function only used to test the module
+if __name__ == "__main__":
+ TEST_termcolor()
# \param salome.myStudyId : active Study Id
# \param salome.myStudy : the active Study (interface SALOMEDS::Study)
-
+#
from salome_kernel import *
from salome_study import *
from salome_iapp import *
