o I have modified the standard_toolbar picture to remove KDE-specific

window decorations.
o Fix typo in qt_widget.tex
o Fix an error about memory leak: a widget without parent is not
destroyed automatically.

Packages/Qt_widget/doc_tex/Qt_widget/qt_widget.tex

@@ -114,9 +114,6 @@ without the layers.
 The first example draws a red segment on an orange background.
 \ccIncludeExampleCode{Qt_widget/Examples/hellosegment.C}
 
-Note that we call new but not delete. This does not mean that there is 
-a memory leak. It is in Qt's responsability to free widgets.
-
 We follow the \qt\ naming conventions for material properties, for
 example, the {\tt CGAL::BackgroundColor} above.
 
@@ -136,7 +133,7 @@ whenever necessary. This is the topic of the next example.
 
 \subsection{Example: Signals and Slots}
 
-This example is slightly more involved and uses  the central
+This example is slightly more involved and uses  the
 signal/slots mecanism of \qt\ .
 
 The main widget shows a
@@ -172,39 +169,32 @@ the object to which belong the connected slot
 and the slot connected to the signal.
 For instance, the statement:
 \begin{ccExampleCode}
-connect(widget, SIGNAL(redraw_on_back()), this,
-SLOT(redraw_win()));
+connect(widget, SIGNAL(redraw_on_back()),
+        this, SLOT(redraw_win()));
 \end{ccExampleCode}
 
-connects the signal \ccc{redraw_on_back()} of the widget
-\ccc{this} to the slot \ccc{redraw_win()} of the \ccc{QMainWindow}
-widget. Signals and slots of different widget can be connected
-together. Signals and slots can have any type of arguments,
-but a signal and a slot connected together must have the same arguments types. 
+connects the signal \ccc{redraw_on_back()} of the widget \ccc{widget}
+to the slot \ccc{redraw_win()} of the \ccc{QMainWindow} \ccc{his}.
+Signals and slots can have any type of arguments, but a signal and a
+slot connected together must have the same arguments types.
 \end{description}
 
-Every class that defines at least a signal or a slot must 
-be derived from the class \ccc{QObject}, 
-which is done by the macro {\sc Q\_object}.
+Every class that defines at least a signal or a slot must be derived
+from the class \ccc{QObject} and must use the macro {\sc Q\_object}
+inside the private section of its declaration. You also need to run
+\ccc{moc}, the \emph{Meta Object Compiler} supplied with \qt\, on the
+file that contains the class declaration.
 
-Whenever you define a class of your own that uses \ccc{signals} and/or
-\ccc{slots}, it is not enough to simply compile it. You must also run
-\ccc{moc}, the Meta-Object Compiler supplied with \qt\, on the file
-that contains the class declaration. Running \ccc{moc} outputs glue
-code that
-is needed for the signal/slot mechanism to work. You have two
-possibilities to add this glue code to your application: either you
-include the code generated by \ccc{moc} in one of your source files or 
-you compile the code generated by \ccc{moc} separately and link it to your
-application.\footnote{See the \qt\ documentation related to signals/slots/moc.}
+\ccc{moc} is a pre-compiler that produces the \emph{meta object} code
+of each class that uses the macro {\sc Q\_object}. This \emph{meta
+  object} code is needed by the signal/slot mecanism. There are
+several methods to compile the outputs of \ccc{moc}. In CGAL, we have
+chosen to include the outputs of \ccc{moc} in a source files. See the
+\qt\ documentation on \ccc{moc} for other possibilities.
 
 The line \ccc{//moc_source_file : tutorial2.C} is for users that use
 makefiles. This line tells to the \cgal\ makefile generator that
 \ccc{tutorial2.C} should be the file that \ccc{moc} should be run on.
- This is useful when you
-have some header files in different directories and you want that
-\ccc{moc} parse them and include the code in the right files. If you
-are not using makefiles you should not be concerned about this line.
 
 Let us come back to the control flow in the above example.
 The main widget of the application is the widget \ccc{w}
@@ -224,7 +214,7 @@ of  \ccc{My_window} which actually draws the triangulation.
 Note that the  \ccc{Qt_widget}  emits the same signal
 \ccc{redraw_on_back()} when the window is resized. Thus,
 the signals/slots connection  ensures that the
-triangulation is redrawn  each time the window is resized.
+triangulation is redrawn  each time the redrawing is needed.
 
 
 \begin{ccAdvanced}
@@ -237,6 +227,13 @@ method. The most recommended way is to use layers, that are described
 in the next section.
 \end{ccAdvanced}
 
+Note that in that example, the \ccc{My_window} constructor calls
+\ccc{new} to allocate a new \ccc{Qt_widget} object but \ccc{delete} is
+never called to deallocate it. This does not mean that there is a
+memory leak. It is in Qt's responsability to free widgets that have a
+parent. In that example the \ccc{My_window} object is the parent of
+\ccc{widget} and will deallocate it automatically at its destruction.
+
 \section{Layers}
 \label{Qt_widget_layers}
 \subsection{Using Layers to Draw}
@@ -252,7 +249,7 @@ layers. Besides better code, layers have the advantage that they can
 be activated and deactivated at runtime. Finally, more modularity
 means a higher potential for reuse.
 
-A layer can be {\em attached} to a \ccc{Qt_widget}. The \ccc{draw()}
+A layer can be {\em attached} to a \ccc{Qt_widget}. The \ccc{redraw()}
 member function of the \ccc{Qt_widget} calls
 the method \ccc{Qt_widget_layer::draw()} of all attached layers, in the
 order that they were attached. It is a very simple rule: the last layer

Packages/Qt_widget/doc_tex/support/Qt_widget/qt_widget.tex

@@ -114,9 +114,6 @@ without the layers.
 The first example draws a red segment on an orange background.
 \ccIncludeExampleCode{Qt_widget/Examples/hellosegment.C}
 
-Note that we call new but not delete. This does not mean that there is 
-a memory leak. It is in Qt's responsability to free widgets.
-
 We follow the \qt\ naming conventions for material properties, for
 example, the {\tt CGAL::BackgroundColor} above.
 
@@ -136,7 +133,7 @@ whenever necessary. This is the topic of the next example.
 
 \subsection{Example: Signals and Slots}
 
-This example is slightly more involved and uses  the central
+This example is slightly more involved and uses  the
 signal/slots mecanism of \qt\ .
 
 The main widget shows a
@@ -172,39 +169,32 @@ the object to which belong the connected slot
 and the slot connected to the signal.
 For instance, the statement:
 \begin{ccExampleCode}
-connect(widget, SIGNAL(redraw_on_back()), this,
-SLOT(redraw_win()));
+connect(widget, SIGNAL(redraw_on_back()),
+        this, SLOT(redraw_win()));
 \end{ccExampleCode}
 
-connects the signal \ccc{redraw_on_back()} of the widget
-\ccc{this} to the slot \ccc{redraw_win()} of the \ccc{QMainWindow}
-widget. Signals and slots of different widget can be connected
-together. Signals and slots can have any type of arguments,
-but a signal and a slot connected together must have the same arguments types. 
+connects the signal \ccc{redraw_on_back()} of the widget \ccc{widget}
+to the slot \ccc{redraw_win()} of the \ccc{QMainWindow} \ccc{his}.
+Signals and slots can have any type of arguments, but a signal and a
+slot connected together must have the same arguments types.
 \end{description}
 
-Every class that defines at least a signal or a slot must 
-be derived from the class \ccc{QObject}, 
-which is done by the macro {\sc Q\_object}.
+Every class that defines at least a signal or a slot must be derived
+from the class \ccc{QObject} and must use the macro {\sc Q\_object}
+inside the private section of its declaration. You also need to run
+\ccc{moc}, the \emph{Meta Object Compiler} supplied with \qt\, on the
+file that contains the class declaration.
 
-Whenever you define a class of your own that uses \ccc{signals} and/or
-\ccc{slots}, it is not enough to simply compile it. You must also run
-\ccc{moc}, the Meta-Object Compiler supplied with \qt\, on the file
-that contains the class declaration. Running \ccc{moc} outputs glue
-code that
-is needed for the signal/slot mechanism to work. You have two
-possibilities to add this glue code to your application: either you
-include the code generated by \ccc{moc} in one of your source files or 
-you compile the code generated by \ccc{moc} separately and link it to your
-application.\footnote{See the \qt\ documentation related to signals/slots/moc.}
+\ccc{moc} is a pre-compiler that produces the \emph{meta object} code
+of each class that uses the macro {\sc Q\_object}. This \emph{meta
+  object} code is needed by the signal/slot mecanism. There are
+several methods to compile the outputs of \ccc{moc}. In CGAL, we have
+chosen to include the outputs of \ccc{moc} in a source files. See the
+\qt\ documentation on \ccc{moc} for other possibilities.
 
 The line \ccc{//moc_source_file : tutorial2.C} is for users that use
 makefiles. This line tells to the \cgal\ makefile generator that
 \ccc{tutorial2.C} should be the file that \ccc{moc} should be run on.
- This is useful when you
-have some header files in different directories and you want that
-\ccc{moc} parse them and include the code in the right files. If you
-are not using makefiles you should not be concerned about this line.
 
 Let us come back to the control flow in the above example.
 The main widget of the application is the widget \ccc{w}
@@ -224,7 +214,7 @@ of  \ccc{My_window} which actually draws the triangulation.
 Note that the  \ccc{Qt_widget}  emits the same signal
 \ccc{redraw_on_back()} when the window is resized. Thus,
 the signals/slots connection  ensures that the
-triangulation is redrawn  each time the window is resized.
+triangulation is redrawn  each time the redrawing is needed.
 
 
 \begin{ccAdvanced}
@@ -237,6 +227,13 @@ method. The most recommended way is to use layers, that are described
 in the next section.
 \end{ccAdvanced}
 
+Note that in that example, the \ccc{My_window} constructor calls
+\ccc{new} to allocate a new \ccc{Qt_widget} object but \ccc{delete} is
+never called to deallocate it. This does not mean that there is a
+memory leak. It is in Qt's responsability to free widgets that have a
+parent. In that example the \ccc{My_window} object is the parent of
+\ccc{widget} and will deallocate it automatically at its destruction.
+
 \section{Layers}
 \label{Qt_widget_layers}
 \subsection{Using Layers to Draw}
@@ -252,7 +249,7 @@ layers. Besides better code, layers have the advantage that they can
 be activated and deactivated at runtime. Finally, more modularity
 means a higher potential for reuse.
 
-A layer can be {\em attached} to a \ccc{Qt_widget}. The \ccc{draw()}
+A layer can be {\em attached} to a \ccc{Qt_widget}. The \ccc{redraw()}
 member function of the \ccc{Qt_widget} calls
 the method \ccc{Qt_widget_layer::draw()} of all attached layers, in the
 order that they were attached. It is a very simple rule: the last layer