From: vsr Date: Mon, 14 May 2012 05:09:11 +0000 (+0000) Subject: Update user documentation X-Git-Tag: V6_5_0~1 X-Git-Url: http://git.salome-platform.org/gitweb/?a=commitdiff_plain;h=73c6ccb14880bd0798527ec009875209000a7b75;p=modules%2Fgui.git Update user documentation --- diff --git a/doc/salome/gui/input/howtos_and_best_practives.doc b/doc/salome/gui/input/howtos_and_best_practives.doc index 40e3d6879..e064bf281 100644 --- a/doc/salome/gui/input/howtos_and_best_practives.doc +++ b/doc/salome/gui/input/howtos_and_best_practives.doc @@ -22,28 +22,29 @@ data server, namely \c SALOMEDS::StudyBuilder. As soon as data entities are publ in the study, they are shown in the Object browser, in the same order as they appear in the study tree. Re-arrangement of the data entities with such approach is not a trivial task: for example, when copying/moving any data entity at the new position -within the tree, it is necessary to copy all its attributes also and clear (in case -of move operation) data entity at the original position. Also, it is not possible to -have some data items in the tree "invisible" for the user (though it might be useful). +within the tree, it is necessary to copy all its attributes as well +and to clear (in case of move operation) the data entity at the original position. Also, it is not possible to +make some data items in the tree "invisible" for the user (though it might be useful). -Use case builder provides alternative and more flexible way for customizing of the +Use case builder provides an alternative and more flexible way for customizing the data tree representation. It implements another approach to the data tree hierarchy, based on the tree node attributes. With use case builder it is possible to arrange and easily re-arrange the data items in the data tree in any appropriate way. -For example, with use case builder it is easy to implement such operations like +For example, with use case builder it is easy to implement such operations as \ref drag_and_drop "Drag and Drop" and Copy/Cut/Paste. With use case builder approach -it's not important how data entities are arranged in the study tree, they even may be -lying on the same level - use case builder allows providing custom data tree +it is not important how data entities are arranged in the study tree, they even may +lie on the same level - use case builder allows providing custom data tree representation, completely indepedent on the study data tree itself. It is even possible to hide some data entities in the tree representation while still keeping them in the study (to store specific module data). -Object browser automatically checks it the module root data object contains tree node -attribute and switches to the browsing of the data tree for such module using use case -builder. Otherwise, it browses data using ordinary study tree iterator. Thus, it is +Object browser automatically checks it the module root data object +contains a tree node attribute and switches to the browsing of the +data tree for such module using the use case +builder. Otherwise, it browses data using an ordinary study tree iterator. Thus, it is possible to have in the same study some modules based on use case builder approach and -other ones not using it. +others not using it. \section use_case_builder_usage Use case builder usage @@ -59,26 +60,27 @@ interface Study \endcode \c SALOMEDS::UseCaseBuilder interface of the \c SALOMEDS CORBA module provides several -methods that can be used to build custom data tree. Its API is similar to that one of +methods that can be used to build a custom data tree. Its API is +similar to the API of \c SALOMEDS::StudyBuilder interface - it operates with terms \a "father object" and \a "child object". In addition, use case builder uses term \a "current object" that is -used as a parent of the children objects being added if parent is not explicitly +used as a parent of the children objects added if the parent is not explicitly specified. \code interface UseCaseBuilder { - // Set top-level root object of the use case tree as current + // Set top-level root object of the use case tree as the current one. // This method is usually used to add SComponent items to the top level of the tree boolean SetRootCurrent(); - // Set the object theObject as current object of the use case builder + // Set the object theObject as the current object of the use case builder boolean SetCurrentObject(in SObject theObject); // Append object SObject to the end of children list of the current object boolean Append(in SObject theObject); - // Append object SObject to the end of children list of parent object theFather + // Append object SObject to the end of children list of the parent object theFather boolean AppendTo(in SObject theFather, in SObject theObject); // Insert object theFirst before the object theNext (under the same parent object) @@ -111,7 +113,7 @@ interface: \code interface UseCaseBuilder { - // Get reference to the use case iterator and initialize it + // Get a reference to the use case iterator and initialize it // by the given object theObject UseCaseIterator GetUseCaseIterator(in SObject theObject); }; @@ -125,13 +127,13 @@ interface UseCaseIterator { // Activate or reset use case iterator; boolean parameter allLevels // specifies if the iterator should browse recursively on all sub-levels or - // on the first sub-level only + // on the first sub-level only. void Init(in boolean allLevels); - // Check if iterator can browse to the next item + // Check if the iterator can browse to the next item boolean More(); - // Browse iterator to the next object + // Browse the iterator to the next object void Next(); - // Get object currently pointed by the iterator + // Get the object currently pointed by the iterator SObject Value(); }; \endcode @@ -142,12 +144,12 @@ Typical usage of the \c UseCaseIterator is as follows: // get use case builder SALOMEDS::UseCaseBuilder_var useCaseBuilder = study->GetUseCaseBuilder(); -// get use case iterator +// get the use case iterator SALOMEDS::UseCaseIterator_var iter = useCaseIter->GetUseCaseIterator( sobject.in() ); // iterate through the sub-items recursively for ( useCaseIter->Init( true ); useCaseIter->More(); useCaseIter->Next() ) { SALOMEDS::SObject_var child = useCaseIter->Value(); - // do something with child + // do something with the child // ... // clean-up child->UnRegister(); @@ -159,24 +161,25 @@ useCaseBuilder->UnRegister(); \section use_case_compatibility Remark about compatibility with existing studies -If one day you decided to switch your module to the use case builder approach to provide -customization for the data tree representation, you must take care about compatibility -with existing SALOME studies. Basically it means that you have to add simple code to your -module's \c Load() (and \c LoadASCII() if necessary) method, that adds tree node -attributes to all the data entities in your module's data tree. The simplest way to do -this, is to iterate through all the data items and recursively add them to the use case -builder: +If you decide to switch your module to the use case builder approach to provide +customization for the data tree representation, you must take care of compatibility +with existing SALOME studies. Basically it means that you have to add +a simple code to \c Load() (and \c LoadASCII() if necessary) method +of your module, which adds tree node attributes to all data entities +in the data tree of your module. The simplest way to do +this is to iterate through all data items and recursively add them to +the use case builder: \code // find component SALOMEDS::SComponent_var comp = study->FindComponent( "MYMODULE" ); -// add tree node attributes only if component data is present in study +// add tree node attributes only if component data is present in the study if ( !CORBA::is_nil( comp ) ) { - // get use case builder + // get the use case builder SALOMEDS::UseCaseBuilder_var useCaseBuilder = study->GetUseCaseBuilder(); // check if tree nodes are already set if ( !useCaseBuilder->IsUseCaseNode( comp.in() ) ) { - // set use case builder's current node to the root + // set the current node of the use case builder to the root useCaseBuilder->SetRootCurrent(); // add component item to the top level of the use case tree useCaseBuilder->Append( comp.in() ); @@ -185,7 +188,7 @@ if ( !CORBA::is_nil( comp ) ) { for ( iter->InitEx( true ); iter->More(); iter->Next() ) { SALOMEDS::SObject_var sobj = iter->Value(); SALOMEDS::SObject_var father = sobj->GetFather(); - // add object to the corresponding level in the use case tree + // add an object to the corresponding level in the use case tree useCaseBuilder->AppendTo( father.in(), sobj.in() ); // clean up (avoid memory leaks) sobj->UnRegister(); @@ -200,25 +203,25 @@ if ( !CORBA::is_nil( comp ) ) { \tableofcontents -Drag and Drop provides a simple visual mechanism which users can use to transfer +Drag and Drop provides a simple visual mechanism to transfer information between and within applications. -In certain aspect Drag and drop is similar in function to the clipboard's copy/cut/paste +In some aspects Drag and drop operates similarly to the clipboard copy/cut/paste mechanism. Since SALOME GUI is implemented on Qt, the drag and drop functionality support is provided by means of the corresponding Qt mechanisms. -Currently, dragging and dropping of the items can be done within Object browser only, -however this functionality can be extended to other GUI elements also. +Currently dragging and dropping of the items can be done within Object browser only, +however this functionality can be extended to other GUI elements as well. \section enable_drag_and_drop Enabling drag and drop in SALOME module The Drag and drop functionality is enabled by default in the Object browser. However, -to allow dragging of some data object or dropping data on it, it is necessary to redefine +to allow dragging of a data object or dropping data on it, it is necessary to redefine \c isDraggable() and \c isDropAccepted() methods of the corresponding class, a successor of the \c SUIT_DataObject. These methods are defined in the base class \c SUIT_DataObject -and default implementation of both functions return \c false, that prevents dragging and +and default implementation of both functions returns \c false, which prevents dragging and dropping: \code @@ -238,12 +241,12 @@ re-implement these functions in your successor data object class and return \c t when it is needed (for example, depending on the data object type, state, etc). Another alternative is available if your module is directly inherited from -\c LightApp_Module or \c SalomeApp_Module class (as majority of existing SALOME modules). +\c LightApp_Module or \c SalomeApp_Module class (as the majority of existing SALOME modules). The class \c LightApp_Module (and thus \c SalomeApp_Module also) already provides high-level API that can be used for enabling drag and drop functionality. To enable dragging, redefine \c isDraggable() method of your module class. In this method -you can analyze the data object that is a subject of the drag operation and decide if +you can analyze the data object subject to the drag operation and decide if it is necessary to enable or prevent its dragging: \code @@ -262,11 +265,11 @@ bool MyModuleGUI::isDraggable( const SUIT_DataObject* what ) const Note, that you should not invoke here method \c isDragEnabled() of your data object class (in case if it inherits \c LightApp_DataObject or \c SalomeApp_DataObject), unless you redefine methods \c isDraggable() and \c isDropAccepted() in your data object class. -The reason is that \c LightApp_DataObject class's implementation of these methods +The reason is that the implementation of these methods in \c LightApp_DataObject class redirects calls to the \c LightApp_Module - be careful to avoid entering endless recursion loop. -To alllow dropping of the data to some object (the object under the mouse cursor in the +To allow data dropping to an object (the object under the mouse cursor in the Object browser during the drag operation) redefine \c isDropAccepted() method of your module class: @@ -288,8 +291,8 @@ The caution about avoiding recursive loop mentioned above is also valid for \section handle_data_dropping Handling data dropping -When dragging operation is completed (data is dropped to some object) the module owning -the item on which data is dropped to is notified by invoking its \c dropObjects() method: +When dragging operation is completed (the data is dropped to an object) the module owning +the item on which the data is dropped is notified by invoking its \c dropObjects() method: \code void LightApp_Module::dropObjects( const DataObjectList& what, @@ -300,18 +303,18 @@ void LightApp_Module::dropObjects( const DataObjectList& what, } \endcode -Default implementation does nothing. However, this method can be redifined in the -successor class and handle the operation properly. The list of data objects being dropped -is passed via \c what parameter. The data object on which data is being dropped is passed -via \c where parameter. The parameter \c row specifies the position in the children list -of \c where data object at which data is dropped; it this parameter is equal to -1, the -data is dropped to the end of children list. Drop action being performed is passed +The default implementation does nothing. However, this method can be redifined in the +successor class and handle the operation properly. The list of dropped +data objects is passed via \c what parameter. The data object on which +the data is dropped is passed via \c where parameter. The parameter \c row specifies in the children list +the position of object where data is dropped; if this parameter is equal to -1, the +data is dropped to the end of the children list. Performed drop action is passed via \c action parameter; possible values are \c Qt::CopyAction and \c Qt::MoveAction (other actions are currently unsupported). -The method \c dropObjects() should analyze the parameters and apply corresponding actions -for rearrangement of the data tree, copying or moving the data items depending on the -operation being performed. For example: +The method \c dropObjects() should analyze the parameters and apply +the corresponding actions for rearrangement of the data tree, copying or moving the data items depending on the +operation performed. For example: \code void MyModuleGUI::dropObjects( const DataObjectList& what, SUIT_DataObject* where, @@ -344,9 +347,10 @@ In the above code the function \c copyOrMove() performs actual data tree rearran \section drag_drop_light_modules Drag and Drop in "light" modules The data model of the \a light (not having CORBA engine) SALOME module is usually -based on the custom tree of data objects. The general approach is to inherit own data -object class from the \c LightApp_DataObject and own data model from the -\c LightApp_DataModel class. The data model class is responsible for building of the +based on the custom tree of data objects. The general approach is to +inherit a custom data +object class from the \c LightApp_DataObject and a custom data model from the +\c LightApp_DataModel class. The data model class is responsible for building the appropriate presentation of the data tree in the Object browser. Thus, the implementation of the drag and drop functionality in a \a light module (more @@ -358,14 +362,14 @@ tree representation automatically, as soon as \c updateObjectBrowser() function \section drag_drop_full_modules Using UseCaseBuilder for Drag and Drop handling in "full" modules Drag and drop operation requires underlying data model to allow flexible re-arrangement of -the data entities inside the data tree. However, in a \a full (CORBA engine based) SALOME +the data entities inside the data tree. In a \a full (CORBA engine based) SALOME module, which data model is usually based on the hierarchy of \c SALOMEDS::SObject entities -provided by the data server functionality, re-arrangement of the data tree is not a trivial -task. +provided by the data server functionality, re-arrangement of the data +tree is not a trivial task. -However, SALOME data server (\c SALOMEDS) CORBA module proposes mechanism that can be used -to customize data tree representation in a simple and flexible way - \ref use_case_builder -"use case builder". +However, SALOME data server (\c SALOMEDS) CORBA module proposes a mechanism that can be used +to customize data tree representation in a simple and flexible way - +\ref use_case_builder "use case builder". With use case builder, the \c dropObjects() function can be easily implemented. For example: @@ -421,7 +425,7 @@ void MyModule::copyOrMove( const MYMODULE_ORB::object_list& what, SALOMEDS::SObject_var objAfter; if ( row >= 0 && useCaseBuilder->HasChildren( where ) ) { - // insert at given row -> find insertion position + // insert at a given row -> find insertion position SALOMEDS::UseCaseIterator_var useCaseIt = useCaseBuilder->GetUseCaseIterator( where ); int i; for ( i = 0; i < row && useCaseIt->More(); i++, useCaseIt->Next() ); @@ -435,21 +439,22 @@ void MyModule::copyOrMove( const MYMODULE_ORB::object_list& what, if ( CORBA::is_nil( sobj ) ) continue; // skip bad object if ( isCopy ) { // copying is performed - // get name of the object + // get the name of the object CORBA::String_var name = sobj->GetName(); - // create new object, as a child of the component object + // create a new object, as a child of the component object SALOMEDS::SObject_var new_sobj = studyBuilder->NewObject( father ); new_sobj->SetAttrString( "AttributeName", name.in() ); sobj = new_sobj; // ... perform other necessary data copying like - // adding corresponding attributes or creation - // of a servant data entities... + // adding the corresponding attributes or creation + // of servant data entities... } // insert the object or its copy to the use case tree if ( !CORBA::is_nil( objAfter ) ) - useCaseBuilder->InsertBefore( sobj, objAfter ); // insert at given row + useCaseBuilder->InsertBefore( sobj, objAfter ); // insert at a given row else - useCaseBuilder->AppendTo( where, sobj ); // append to the end of list + useCaseBuilder->AppendTo( where, sobj ); // append to the + end of the list } } diff --git a/doc/salome/gui/input/introduction_to_gui.doc b/doc/salome/gui/input/introduction_to_gui.doc index 3ff4b9920..fe6a24423 100644 --- a/doc/salome/gui/input/introduction_to_gui.doc +++ b/doc/salome/gui/input/introduction_to_gui.doc @@ -54,12 +54,7 @@ appropriate help page can also be called from any operation dialog via Help for the GUI module provides information about standard -\subpage viewers_page "Salome Viewers": - +\subpage viewers_page "Salome Viewers". General application preferences are described in the \subpage setting_preferences_page "Preferences" section of SALOME GUI Help. diff --git a/doc/salome/gui/input/plot2d_viewer.doc b/doc/salome/gui/input/plot2d_viewer.doc index d84c99c33..11640c348 100644 --- a/doc/salome/gui/input/plot2d_viewer.doc +++ b/doc/salome/gui/input/plot2d_viewer.doc @@ -47,50 +47,48 @@ presenting all displayed objects in the visible area. \image html plot2d_points.png -Draw Points - switch display mode to the \em Points mode. In +Draw Points - switches display mode to \em Points. In this mode, each curve is displayed as a set of points.
\image html plot2d_lines.png -Draw Lines - switch display mode to the \em Lines mode. In this -mode, each curve is represented as a set of the plain line segments. +Draw Lines - switches display mode to \em Lines. In this +mode, each curve is represented as a set of plain line segments.
\image html plot2d_splines.png -Draw Splines - switch display mode to the \em Splines mode. In +Draw Splines - switches display mode to \em Splines. In this mode, each curve is represented as a spline.
\image html plot2d_lmin_normalization.png -Normalization to global minimum by left Y axis - switch -normalization mode to the Left Y Axis: Minimum normalization -mode. In this mode, all curves are normalized to the global minimum by -left Y axis. +Normalization to global minimum by left Y axis - switches +normalization mode to Left Y Axis: Minimum normalization. +In this mode, all curves are normalized to the global minimum by the left Y axis. \image html plot2d_lmax_normalization.png -Normalization to global maximum by left Y axis - switch -normalization mode to the Left Y Axis: Maximum normalization -mode. In this mode, all curves are normalized to the global maximum by -left Y axis. +Normalization to global maximum by left Y axis - switches +normalization mode to Left Y Axis: Maximum normalization. +In this mode, all curves are normalized to the global maximum by the left Y axis.
\image html plot2d_rmin_normalization.png -Normalization to global minimum by right Y axis - switch -normalization mode to the Right Y Axis: Minimum normalization -mode. In this mode, all curves are normalized to the global minimum by -right Y axis. +Normalization to global minimum by right Y axis - switches +normalization mode to Right Y Axis: Minimum normalization. +In this mode, all curves are normalized to the global minimum by +the right Y axis. \image html plot2d_rmax_normalization.png Normalization to global maximum by right Y axis - switch -normalization mode to the Right Y Axis: Maximum normalization -mode. In this mode, all curves are normalized to the global maximum by -right Y axis. +normalization mode to Right Y Axis: Maximum normalization. +In this mode, all curves are normalized to the global maximum by +the right Y axis.
\image html plot2d_linear.png @@ -151,8 +149,8 @@ The options are as follows: - Background color of the XY plot. -- Deviation marker here you can specify the properties of the - marker, which used for the drawing deviations data. +- Deviation marker allows specifying the properties of the + marker, which is used for drawing deviations data. - Line width line width of the marker. @@ -161,26 +159,26 @@ The options are as follows: - Color color of the marker. -- Normalization here you can select the type of - normalization(\em minimum or/and \em maximum) for the displayed - presentations of the 2d curves in the view. +- Normalization allows selecting the type of + normalization (\em minimum or/and \em maximum) for the displayed + presentations of 2d curves in the view. -- Scale mode here you can select the type of scaling (\em Linear +- Scale mode allows selecting the type of scaling (\em Linear or \em Logarithmic) for X (Horizontal) or Y (Vertical) axes separately. Note that the \em Logarithmic scale can be used only if the minimum value of corresponding component (abscissa or ordinate) of all points displayed in the viewer is greater than zero. -- Axis ... options group allows to specify additional settings +- Axis ... options group allows specifying additional settings for each axis separately: - - Axis title - an axis title + - Axis title - an axis title. - - Grid / Axes marks here you can define the maximum number - of major and minor scale divisions for a specified axis. The real + - Grid / Axes marks allows defining the maximum number + of major and minor scale divisions for a given axis. The real number of intervals fits to {1,2,5}*10^N, where N is a natural - number, and doesn't exceed the maximum. + number, and does not exceed the maximum. - Save settings as default If this check box is marked, all XY plots will be displayed with these defined properties. @@ -191,7 +189,7 @@ The options are as follows: \image html plot2d_analytical_curve.png Analytical curves - provides an access to the analytical curves -dialog box, that allows to add, remove and modify analytical curves +dialog box that allows to add, remove and modify analytical curves for the Plot 2d Viewer. \image html analytical_curves_dlg.png @@ -200,29 +198,31 @@ The options are as follows: - Curve parameters: - - y(x)= allows to specify python expression, which used to - calculate coordinates of the points of the curve, - x corresponds to the shown in the plot 2d viewer horizontal range. - - Nb. itervals allows to specify number of the points of the - curve. + - y(x)= allows specifying a python expression, which is used to + calculate the coordinates of the curve points, where x + corresponds to the horizontal range, shown in plot 2D viewer. + + - Nb. itervals allows specifying the number of the curve points. - Curve properties: - - Auto assign if it is checked, properties of the curves - (Line type, Line width, Marker type and Color) assigned - automatically.To define the properties of the curve manually - remove the checkmark from this control. + - Auto assign if checked, the properties + (Line type, Line width, Marker type and + Color) are assigned to curves automatically. To define + the curve properties manually, uncheck this control. - - Line type allows to choose curve's line type from (None, - Solid, Dash, Dot, Dash - Dot, Dash - Dot - Dot). + - Line type allows to choose curve line type from \em None, + \em Solid, \em Dash, \em Dot, Dash - Dot and + Dash - Dot - Dot. - Line width allows to specify line width of the curve. - - Marker type allows to choose curve's marker type from - (Circle, Rectangle, Diamond, Rightward, Leftward, Downward & - Upward Triangle, Cross or Diagonal Cross). + - Marker type allows to choose curve marker type from + \em Circle, \em Rectangle, \em Diamond, Rightward Triangle, + Leftward Triangle, Downward Triangle, + Upward Triangle, \em Cross and Diagonal Cross). - - Color allows to specify color of the curve. + - Color allows specifying the curve color.
@@ -233,6 +233,6 @@ The options are as follows: \image html plot2d_print.png -Print view - print view scene. +Print view - prints the current view scene. */ diff --git a/doc/salome/gui/input/setting_preferences.doc b/doc/salome/gui/input/setting_preferences.doc index 9415ebc31..c85fc8e29 100644 --- a/doc/salome/gui/input/setting_preferences.doc +++ b/doc/salome/gui/input/setting_preferences.doc @@ -3,31 +3,30 @@ \page setting_preferences_page Setting Preferences All user preferences of \b SALOME application can be customized using the -common \b Preferences dialog box. This dialog can be invoked using the +common \b Preferences dialog box. This dialog can be open using the File > Preferences... menu item. The \b Preferences dialog box consists of two parts: -- Available preferences sections are listed at the left of the dialog +- Available preferences sections are listed in the left part of the dialog box; usually this list contains "SALOME" item that specifies general -application preferences and separate section for each SALOME module +application preferences and a separate section for each SALOME module available in the current session. - The tabbed widget at the right side of the dialog box provides controls that can be used to customize the preferences. -\note The preferences for the modules become accessible only after -explicit loading of these modules. Until that time the dialog box will -show corresponding warning message. +\note The preferences for modules become accessible only after +explicit loading of these modules. Until then the dialog box will +show the corresponding warning message. -More detailed information about certain module preferences can be found in the User's guide of the corresponding module. +More detailed information about preferences for certain modules can be found in the User's guide of the corresponding module. -General application preferences are specified at the \b SALOME section +General application preferences are specified in the \b SALOME section of the \b Preferences dialog box. These preferences affect on the application look-n-feel and common functionality. -If you've just started your study and haven't yet loaded other -modules, you'll be able to change only those settings, which refer to -the whole GUI SALOME session. These settings will be valid for the -whole study session. +If the study has just been started and other +modules have not been loaded yet, it will be possible to change only the settings which refer to +the whole GUI SALOME session.

General Preferences

@@ -300,7 +299,7 @@ Import dialog box. \image html import.png The preferences files usually have *.xml extension. Also, -preferences files automatically saved by application (stored in the +preferences files automatically saved by the application (stored in the ~/.config/salome directory) have no extension and by default start with .SalomeApprc. followed by SALOME version number. Usually there is a separate preferences file for each SALOME version in use. Preferences diff --git a/doc/salome/gui/input/using_pluginsmanager.doc b/doc/salome/gui/input/using_pluginsmanager.doc index 4fbe74107..c8e5ec6c0 100644 --- a/doc/salome/gui/input/using_pluginsmanager.doc +++ b/doc/salome/gui/input/using_pluginsmanager.doc @@ -147,23 +147,22 @@ Move this script in the directory \section S4_SALOMEPLUGINS How to select an object of the object browser Sometimes it can be useful to retrieve an object of the object browser to perform -an action on it. For example it can be useful to select a mesh in order -to display some information related to it. +an action on it, for example, to select a mesh and display some information related to it. -Some important methods and objects to use are the followings: --# context.sg.getObjectBrowser(): useful to connect the signal event +Some important methods and objects to use are as follows: +-# context.sg.getObjectBrowser(): to connect the signal event `selectionChanged()` to a custom slot -# context.salome.sg.getAllSelected(): to get the list of selected object in the object browser -# objId = context.salome.sg.getSelected(0): to get the first selected object in the object browser -# salomeObj = context.salome.study.FindObjectID(objId).GetObject(): - to retrieve the salome object from the selection. It can be a GEOM, SMESH, or any + to retrieve the salome object from selection. It can be a GEOM, SMESH, or any other module object. If it is a mesh, then it is possible to call GetMEDMesh() on the object. - If it is not a mesh, this call will raise an exception. Then a possible way to get - a mesh can be written as following: + If it is not a mesh, this call will raise an exception. + So it is possible to write the mesh retrieval in the following way: \code mesh = None try: @@ -172,13 +171,13 @@ except: print "The selection is not a mesh" \endcode -A example of usage of those methods is available with the demo examples. +A example of those methods is available with the demo examples. See the next chapter \ref S5_SALOMEPLUGINS. \section S5_SALOMEPLUGINS Other examples -The GUI module provides you with some basic demo examples, located in -the directory src/SalomeApp/pluginsdemo of the source space, and +The GUI module provides you with some basic demo examples located in +the directory src/SalomeApp/pluginsdemo of the source space and installed in the directory $GUI_ROOT_DIR/share/salome/plugins/gui/demo. \note These examples are automatically installed when you install the GUI diff --git a/doc/salome/gui/input/viewers_chapter.doc b/doc/salome/gui/input/viewers_chapter.doc index 2c588aa41..b3a3b92de 100644 --- a/doc/salome/gui/input/viewers_chapter.doc +++ b/doc/salome/gui/input/viewers_chapter.doc @@ -3,32 +3,31 @@ \page viewers_page Viewers SALOME provides a set of viewers for data representation. SALOME GUI -module includes several types of 2D and 3D viewers, that are used for +module includes several 2D and 3D viewers, that are used for different purposes within the platform: -- \subpage occ_3d_viewer_page "OCC 3D viewer" has been developed on +- \subpage occ_3d_viewer_page has been developed on the basis of Open CASCADE Technology (http://www.opencascade.org). This is the default viewer for SALOME Geometry module, it provids good representation of construction and transformation of geometrical objects. -- \subpage vtk_3d_viewer_page "VTK 3D viewer" has been developed +- \subpage vtk_3d_viewer_page has been developed basing on Kitware Visualization ToolKit library (http://www.vtk.org). This is the default viewer for SALOME Mesh module, where it is used for visualization of meshes. It is also used in SALOME Post-Pro module for all 3D presentations. -- \subpage plot2d_viewer_page "Plot 2D viewer" has been developed +- \subpage plot2d_viewer_page has been developed basing on the open-source Qwt library (http://qwt.sourceforge.net). It is used, for example, for the representation of 2D plots and graphs in the SALOME Post-Pro module. -- \subpage gl_2d_viewer_page GL 2D viewer - general purpose +- \subpage gl_2d_viewer_page is a general purpose OpenGL-based viewer, which can be used for visualization of 2D scenes. This type of viewer is not currently used in SALOME platform -directly, but can be used in the custom modules for the 2D -visualization purposes. +directly, but can be used in custom modules for 2D visualization purposes. -- \subpage qxscene_2d_viewer_page QxScene 2D viewer - it has been +- \subpage qxscene_2d_viewer_page has been developed on the basis of Qt QGraphicsView scene. This viewer is used in SALOME YACS module for visualization of computation schemes.