9 files changed, 49 insertions, 27 deletions
diff --git a/sources/pyside6/doc/conf.py.in b/sources/pyside6/doc/conf.py.in
index 0deea6eb1..16335ac04 100644
--- a/sources/pyside6/doc/conf.py.in
+++ b/sources/pyside6/doc/conf.py.in
@@ -176,7 +176,7 @@ html_logo = "@CMAKE_CURRENT_SOURCE_DIR@/_static/qtforpython.png"
 # 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 = "_static/qtforpython.ico"
+html_favicon = "@CMAKE_CURRENT_SOURCE_DIR@/_static/qtforpython.ico"
 
 # 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,
diff --git a/sources/pyside6/doc/developer/documentation.rst b/sources/pyside6/doc/developer/documentation.rst
index 517bd46f1..2d8d32fcb 100644
--- a/sources/pyside6/doc/developer/documentation.rst
+++ b/sources/pyside6/doc/developer/documentation.rst
@@ -67,7 +67,7 @@ The others have main-test drivers for checking.
 
 There are 2 scripts used for determining the inheritance:
 * ``json_inheritance.py`` (env var ``INHERITANCE_FILE``) reads a
-  inheritance.json file containing the class hierarchy generated by
-  shiboken's doc generator.
+inheritance.json file containing the class hierarchy generated by
+shiboken's doc generator.
 
 * ``import_inheritance.py`` actually tries to import the class (legacy)
diff --git a/sources/pyside6/doc/tools/index.rst b/sources/pyside6/doc/tools/index.rst
index b421a428f..41d4697db 100644
--- a/sources/pyside6/doc/tools/index.rst
+++ b/sources/pyside6/doc/tools/index.rst
@@ -209,3 +209,25 @@ Qt Quick 3D
         :link-type: ref
 
         a graphical user interface for the ``pyside6-balsam`` tool.
+
+.. toctree::
+    :hidden:
+
+    pyside-assistant
+    pyside-designer
+    pyside-genpyi
+    pyside-linguist
+    pyside-lrelease
+    pyside-lupdate
+    pyside-metaobjectdump
+    pyside-project
+    pyside-qml
+    pyside-qmlcachegen
+    pyside-qmllint
+    pyside-qmltyperegistrar
+    pyside-rcc
+    pyside-uic
+    pyside6-balsam
+    pyside6-balsamui
+    pyside6-qmlimportscanner
+    pyside6-qsb
diff --git a/sources/shiboken6/doc/examples/index.rst b/sources/shiboken6/doc/examples/index.rst
index e3575bc06..906cf9b86 100644
--- a/sources/shiboken6/doc/examples/index.rst
+++ b/sources/shiboken6/doc/examples/index.rst
@@ -15,9 +15,9 @@ C++ examples
     .. grid-item-card:: Scriptable Application
         :class-item: cover-img
         :link: ../../examples/example_scriptableapplication_scriptableapplication.html
-        :img-top: ../../../_images/example_no_image.png
+        :img-top: ../../../pyside6/doc/example_no_image.png
 
     .. grid-item-card:: Widget Binding
         :class-item: cover-img
         :link: ../../examples/example_widgetbinding_widgetbinding.html
-        :img-top: ../../../_images/example_no_image.png
+        :img-top: ../../../pyside6/doc/example_no_image.png
diff --git a/sources/shiboken6/doc/shibokengenerator.rst b/sources/shiboken6/doc/shibokengenerator.rst
index 14340ab69..411b14885 100644
--- a/sources/shiboken6/doc/shibokengenerator.rst
+++ b/sources/shiboken6/doc/shibokengenerator.rst
@@ -60,7 +60,7 @@ the typesystem and, in most cases, the injected code.
     well to prevent the headers from being suppressed in the generated
     code.
 
-::ref:`typesystem`: XML files that provides the developer with a tool to customize the
+::ref:`typesystem_details`: XML files that provides the developer with a tool to customize the
              way that the generators will see the classes and functions. For
              example, functions can be renamed, have its signature changed and
              many other actions.
diff --git a/sources/shiboken6/doc/typesystem_manipulating_objects.rst b/sources/shiboken6/doc/typesystem_manipulating_objects.rst
index e024cdf00..7d7074878 100644
--- a/sources/shiboken6/doc/typesystem_manipulating_objects.rst
+++ b/sources/shiboken6/doc/typesystem_manipulating_objects.rst
@@ -268,7 +268,7 @@ add-function
 
 The ``add-function`` node allows you to add a given function onto the target
 language, and it is a child of an :ref:`object-type` or :ref:`value-type` nodes if the
-function is supposed to be a method, or :ref:`namespace` and :ref:`typesystem` if
+function is supposed to be a method, or :ref:`namespace` and :ref:`typesystem_details` if
 the function is supposed to be a function inside a namespace or a global function.
 It may contain :ref:`modify-argument` nodes.
 
@@ -333,7 +333,7 @@ declare-function
 The ``declare-function`` node allows you to declare a function present in
 the type and it is a child of an :ref:`object-type` or :ref:`value-type` nodes
 if the function is supposed to be a method, or :ref:`namespace` and
-:ref:`typesystem` if the function is supposed to be a function inside a
+:ref:`typesystem_details` if the function is supposed to be a function inside a
 namespace or a global function. It may contain :ref:`modify-argument` nodes.
 
 .. code-block:: xml
diff --git a/sources/shiboken6/doc/typesystem_solving_compilation.rst b/sources/shiboken6/doc/typesystem_solving_compilation.rst
index 705c2cd26..a8c2010d1 100644
--- a/sources/shiboken6/doc/typesystem_solving_compilation.rst
+++ b/sources/shiboken6/doc/typesystem_solving_compilation.rst
@@ -8,7 +8,7 @@ suppress-warning
 
 The generator will generate several warnings which may be irrelevant to the
 user. The ``suppress-warning`` node suppresses the specified warning, and it is
-a child of the :ref:`typesystem` node.
+a child of the :ref:`typesystem_details` node.
 
 .. code-block:: xml
 
@@ -27,7 +27,7 @@ extra-includes
 
 The ``extra-includes`` node contains declarations of additional include files,
 and it can be a child of the :ref:`namespace`, :ref:`value-type`,
-:ref:`object-type` and :ref:`typesystem` and nodes.
+:ref:`object-type` and :ref:`typesystem_details` and nodes.
 
 The generator automatically tries to read the global header for each type but
 sometimes it is required to include extra files in the generated C++ code to
@@ -48,7 +48,7 @@ the file is located in $INCLUDEPATH and will be included using #include <...>,
 *local* means that the file is in a local directory and will be included
 using #include "...".
 
-When specified as a child of the :ref:`typesystem` node, the include
+When specified as a child of the :ref:`typesystem_details` node, the include
 directives are added to the module source file which contains
 the type converter and registration code. It can be used to specify
 additional includes required for the converter code snippets.
diff --git a/sources/shiboken6/doc/typesystem_specifying_types.rst b/sources/shiboken6/doc/typesystem_specifying_types.rst
index e979c4ee2..3ae36492c 100644
--- a/sources/shiboken6/doc/typesystem_specifying_types.rst
+++ b/sources/shiboken6/doc/typesystem_specifying_types.rst
@@ -25,7 +25,7 @@ in the type system paths passed as command line argument.
 Note that this is not a standard externally parsed entity due to the limitations
 of the underlying parser.
 
-.. _typesystem:
+.. _typesystem_details:
 
 typesystem
 ^^^^^^^^^^
@@ -93,7 +93,7 @@ load-typesystem
 
 The ``load-typesystem`` node specifies which type systems to load when mapping
 multiple libraries to another language or basing one library on another, and
-it is a child of the :ref:`typesystem` node.
+it is a child of the :ref:`typesystem_details` node.
 
 .. code-block:: xml
 
@@ -116,7 +116,7 @@ rejection
 ^^^^^^^^^
 
 The ``rejection`` node rejects the given class, or the specified function
-or field, and it is a child of the :ref:`typesystem` node.
+or field, and it is a child of the :ref:`typesystem_details` node.
 
 .. code-block:: xml
 
@@ -141,7 +141,7 @@ primitive-type
 ^^^^^^^^^^^^^^
 
 The ``primitive-type`` node describes how a primitive type is mapped from C++ to
-the target language, and is a child of the :ref:`typesystem` node. It may
+the target language, and is a child of the :ref:`typesystem_details` node. It may
 contain :ref:`conversion-rule` child nodes. Note that most primitives are
 already specified in the QtCore typesystem (see :ref:`primitive-cpp-types`).
 
@@ -203,7 +203,7 @@ namespace-type
 ^^^^^^^^^^^^^^
 
 The ``namespace-type`` node maps the given C++ namespace to the target
-language, and it is a child of the :ref:`typesystem` node or other
+language, and it is a child of the :ref:`typesystem_details` node or other
 ``namespace-type`` nodes. It may contain :ref:`add-function`,
 :ref:`declare-function`, :ref:`enum-type`, :ref:`extra-includes`,
 :ref:`include-element`, :ref:`modify-function`, ``namespace-type``,
@@ -267,7 +267,7 @@ enum-type
 ^^^^^^^^^
 
 The ``enum-type`` node maps the given enum from C++ to the target language,
-and it is a child of the :ref:`typesystem` node. Use
+and it is a child of the :ref:`typesystem_details` node. Use
 :ref:`reject-enum-value` child nodes to reject values.
 
 .. code-block:: xml
@@ -350,7 +350,7 @@ value-type
 
 The ``value-type`` node indicates that the given C++ type is mapped onto the target
 language as a value type. This means that it is an object passed by value on C++,
-i.e. it is stored in the function call stack. It is a child of the :ref:`typesystem`
+i.e. it is stored in the function call stack. It is a child of the :ref:`typesystem_details`
 node or other type nodes and may contain :ref:`add-function`, :ref:`add-pymethoddef`,
 :ref:`configuration-element`, :ref:`declare-function`, :ref:`conversion-rule`,
 :ref:`enum-type`, :ref:`extra-includes`, :ref:`include-element`, :ref:`modify-function`,
@@ -429,7 +429,7 @@ object-type
 
 The object-type node indicates that the given C++ type is mapped onto the target
 language as an object type. This means that it is an object passed by pointer on
-C++ and it is stored on the heap. It is a child of the :ref:`typesystem` node
+C++ and it is stored on the heap. It is a child of the :ref:`typesystem_details` node
 or other type nodes and may contain :ref:`add-function`, :ref:`add-pymethoddef`,
 :ref:`configuration-element`, :ref:`declare-function`, :ref:`enum-type`,
 :ref:`extra-includes`, :ref:`include-element`, :ref:`modify-function`,
@@ -551,7 +551,7 @@ container-type
 
 The ``container-type`` node indicates that the given class is a container and
 must be handled using one of the conversion helpers provided by attribute **type**.
-It is a child of the :ref:`typesystem` node and may contain
+It is a child of the :ref:`typesystem_details` node and may contain
 :ref:`conversion-rule` child nodes.
 
 .. code-block:: xml
@@ -596,7 +596,7 @@ opaque-container
 The ``opaque-container`` element can be used to add further instantiations
 of :ref:`opaque containers <opaque-containers>` to existing container types
 (built-in or specified by :ref:`container-type` in included modules).
-It is a child of the :ref:`typesystem` node.
+It is a child of the :ref:`typesystem_details` node.
 
 .. code-block:: xml
 
@@ -616,7 +616,7 @@ The ``typedef-type`` node allows for specifying typedefs in the typesystem. They
 are mostly equivalent to spelling out the typedef in the included header, which
 is often complicated when trying to wrap libraries whose source code cannot be
 easily extended.
-It is a child of the :ref:`typesystem` node or other type nodes.
+It is a child of the :ref:`typesystem_details` node or other type nodes.
 
 .. code-block:: xml
 
@@ -652,7 +652,7 @@ The ``custom-type`` node simply makes the parser aware of the existence of a tar
 language type, thus avoiding errors when trying to find a type used in function
 signatures and other places. The proper handling of the custom type is meant to
 be done by a generator using the APIExractor.
-It is a child of the :ref:`typesystem` node.
+It is a child of the :ref:`typesystem_details` node.
 
 .. code-block:: xml
 
@@ -681,7 +681,7 @@ The ``smart pointer`` type node indicates that the given class is a smart pointe
 and requires inserting calls to **getter** to access the pointeee.
 Currently, the usage is limited to function return values.
 **ref-count-method** specifies the name of the method used to do reference counting.
-It is a child of the :ref:`typesystem` node or other type nodes.
+It is a child of the :ref:`typesystem_details` node or other type nodes.
 
 The *optional* attribute **instantiations** specifies for which instantiations
 of the smart pointer wrappers will be generated (comma-separated list).
@@ -785,7 +785,7 @@ function
 ^^^^^^^^
 
 The ``function`` node indicates that the given C++ global function is mapped
-onto the target language. It is a child of the :ref:`typesystem` node
+onto the target language. It is a child of the :ref:`typesystem_details` node
 and may contain a :ref:`modify-function` child node.
 
 .. code-block:: xml
@@ -825,7 +825,7 @@ file or a system include path (indicated by a trailing slash) to be
 parsed. Normally, include files considered to be system include
 files are skipped by the C++ code parser. Its primary use case
 is exposing classes from the STL library.
-It is a child of the :ref:`typesystem` node.
+It is a child of the :ref:`typesystem_details` node.
 
 .. code-block:: xml
 
diff --git a/sources/shiboken6/doc/typesystem_templates.rst b/sources/shiboken6/doc/typesystem_templates.rst
index c32eb97d1..a4ae89a6f 100644
--- a/sources/shiboken6/doc/typesystem_templates.rst
+++ b/sources/shiboken6/doc/typesystem_templates.rst
@@ -10,7 +10,7 @@ template
 
 The ``template`` node registers a template that can be used to avoid
 duplicate code when extending the generated code, and it is a child of the
-:ref:`typesystem` node.
+:ref:`typesystem_details` node.
 
 .. code-block:: xml