diff --git a/doc/Doxyfile b/doc/Doxyfile
index d39543b2..7c3b79dd 100644
--- a/doc/Doxyfile
+++ b/doc/Doxyfile
@@ -943,6 +943,7 @@ WARN_LOGFILE           = Doxygen.log
 INPUT                  = . \
                          classes \
                          ../src \
+                         tutorials \
                          ../README.md
 
 # This tag can be used to specify the character encoding of the source files
diff --git a/doc/tutorials/01-What-is-QSkinny.asciidoc b/doc/tutorials/01-What-is-QSkinny.md
similarity index 52%
rename from doc/tutorials/01-What-is-QSkinny.asciidoc
rename to doc/tutorials/01-What-is-QSkinny.md
index 97aa6274..58da78df 100644
--- a/doc/tutorials/01-What-is-QSkinny.asciidoc
+++ b/doc/tutorials/01-What-is-QSkinny.md
@@ -1,21 +1,19 @@
----
-title: 1. What is QSkinny?
-layout: docs
----
+# Tutorials {#tutorials}
 
-:doctitle: 1. What is QSkinny?
-:notitle:
+## What is QSkinny?
 
 QSkinny is a UI framework based on the Qt graphic stack and written in
 {cpp}. It allows users to write their UIs in {cpp} and/or QML.
 
-.The Fendt Tractor GUI
-image::https://www.fendt.com/de/images/5d19bb4e7b260601c8134e14_1673943667_web_de-DE.jpg[Fendt Tractor GUI]
+**The Fendt Tractor GUI**
+
+![Fendt Tractor GUI](https://www.fendt.com/at/geneva-assets/widget/28282/news-3-low.jpg)
 
 It is currently being used in the Fendt Tractor GUI project, see the
 picture above. For the Fendt Tractor GUI there is no QML used at all;
 the whole codebase is written in {cpp}. An overview of how QSkinny fits
 into the Qt architecture is depicted below:
 
-.QSkinny sits on top of QtQuick, while QML is optional
-image::/doc/tutorials/images/architecture-simple.png[QSkinny architecture]
+**QSkinny sits on top of QtQuick, while QML is optional**
+
+![QSkinny architecture](/doc/tutorials/images/architecture-simple.png)
diff --git a/doc/tutorials/02-Why-QSkinny.asciidoc b/doc/tutorials/02-Why-QSkinny.md
similarity index 56%
rename from doc/tutorials/02-Why-QSkinny.asciidoc
rename to doc/tutorials/02-Why-QSkinny.md
index f743b871..65a2b59d 100644
--- a/doc/tutorials/02-Why-QSkinny.asciidoc
+++ b/doc/tutorials/02-Why-QSkinny.md
@@ -1,10 +1,6 @@
----
-title: 2. Why QSkinny?
-layout: docs
----
+# Tutorials {#tutorials}
 
-:doctitle: 2. Why QSkinny?
-:notitle:
+## Why QSkinny?
 
 The typical questions about QSkinny are: Why was QSkinny created? And why would
 somebody use QSkinny and not QML?
@@ -12,63 +8,62 @@ somebody use QSkinny and not QML?
 Which technology to use always depends on the specific use case. However,
 QSkinny does have some advantages:
 
-== 1. It's {cpp}
+### 1. It's C++
 
-QSkinny is written in {cpp}, so there is no new syntax or programming paradigm
+QSkinny is written in C++, so there is no new syntax or programming paradigm
 to learn as is the case with QML. Of course QSkinny has concepts that
 new programmers need to become familiar with, but they should be understandable
-for people who know {cpp}. Especially programmers experienced with
+for people who know C++. Especially programmers experienced with
 QtWidgets should feel comfortable with QSkinny right away.
 
-=== 1.1 Integration with other build systems / IDEs
+#### 1.1 Integration with other build systems / IDEs
 
-While QtCreator is the natural choice of *IDE* for Qt programmers,
+While QtCreator is the natural choice of **IDE** for Qt programmers,
 some people prefer other IDEs, e.g. Visual
-Studio (Code), Eclipse, CLion etc. Such IDEs usually don't have language support
+Studio (Code), Eclipse, CLion etc. Such IDEs usually don’t have language support
 for QML like type completion and other features. So when using QML you are
 either bound to using QtCreator, or use another IDE and live with the fact that
 the IDE will not understand QML.
 
-When it comes to *build systems*, some QML tools might be hard to integrate:
+When it comes to **build systems**, some QML tools might be hard to integrate:
 For instance in Visual Studio projects it is difficult to invoke the QML
 compiler through the build system.
 
-With QSkinny being written completely in {cpp}, it can be used with any IDE and
+With QSkinny being written completely in C++, it can be used with any IDE and
 should integrate nicely with other build systems. QSkinny is using Qt-specific
 concepts like signals and slots and invokable methods though.
 
-=== 1.2 Use {cpp} tooling for your whole codebase
+#### 1.2 Use C++ tooling for your whole codebase
 
-{cpp} has extensive tooling that assists with writing code, for instance:
+C++ has extensive tooling that assists with writing code, for instance:
 
-- gdb and other debuggers
-- valgrind
-- address sanitizer and other sanitizers
-- static code analysis tools
-- code coverage tools (e.g. gcov)
-- auto test frameworks
-- (a lot more, e.g. clang tools)
+* gdb and other debuggers
+* valgrind
+* address sanitizer and other sanitizers
+* static code analysis tools
+* code coverage tools (e.g. gcov)
+* auto test frameworks
+* (a lot more, e.g. clang tools)
 
 E.g. QtCreator will let you know about potential problems in your code while
 you type, e.g. "unused variable", "calling a virtual method from the constructor
 of a class" etc., and it might even suggest an automatic fix for it.
 
 QML does have some tooling, but its feature set is nowhere near the support of
-{cpp}.
+C++.
 
-When writing your whole codebase in {cpp} with QSkinny, the tooling can be used
+When writing your whole codebase in C++ with QSkinny, the tooling can be used
 for the whole codebase, so also UI code can be debugged, auto tested for a
 CI system, and so on.
 
-In addition, {cpp} has concepts that QML as a declarative language doesn't,
+In addition, C++ has concepts that QML as a declarative language doesn’t,
 like inheritance and overloading. This makes it easier to implement concepts
-like event handling, see <<Styling>> below.
+like event handling, see [Styling](#Styling) below.
 
-
-== 2. Easy data binding
+### 2. Easy data binding
 
 When displaying data from a backend in a QML UI, that data needs to be in a
-certain format: It needs to be made readable by Qt's Meta Object system via
+certain format: It needs to be made readable by Qt’s Meta Object system via
 `Q_PROPERTY`, `Q_INVOKABLE`, `Q_SIGNAL` and others.
 
 Also, for each model that is used in QML there typically needs to be one
@@ -76,19 +71,18 @@ subclass of `QAbstractListModel`, which serves as an adapter class. The process
 of subclassing and implementing virtual methods can be cumbersome, and lead to
 lots of boilerplate code.
 
-QSkinny doesn't need any adaptation layer per se, the data just needs to be
-connected to the frontend with standard {cpp} functionality. Of course classes
+QSkinny doesn’t need any adaptation layer per se, the data just needs to be
+connected to the frontend with standard C++ functionality. Of course classes
 like the aforementioned `QAbstractListModel` can be used when it makes sense,
 but this is up to the user.
 
+### 3. Layouts
 
-== 3. Layouts
-
-Whe it comes to *layouts*, QSkinny has a complete concept of laying out the UI,
+Whe it comes to **layouts**, QSkinny has a complete concept of laying out the UI,
 or in other words: The user can determine in a fine-grained way what happens
 when there is too little or too much space available.
 Concepts like size hints, size policies, stretch factors and others are concepts
-that were already available in QtWidgets and Qt's Graphics View Framework, and
+that were already available in QtWidgets and Qt’s Graphics View Framework, and
 are now supported in QSkinny.
 
 Why are layouts important? QML was created under the premise that in contrast to
@@ -98,33 +92,31 @@ thus size changes will rarely happen.
 This is true for many cases, however layout code gets important when one of the
 following events happen:
 
-- The UI needs to run on two or more screen sizes
-- Language or style changes need to be supported
-- The window is resized, e.g. when the Android virtual keyboard pops up
+* The UI needs to run on two or more screen sizes
+* Language or style changes need to be supported
+* The window is resized, e.g. when the Android virtual keyboard pops up
 
-QSkinny allows the user to take the above use cases into account, but doesn't
+QSkinny allows the user to take the above use cases into account, but doesn’t
 force the developer to write overly complex code: A UI written with QSkinny can
 be coded with fixed sizes for UI elements, as it is typically done in QML.
 
-
-== [[Styling]] 4. Styling / Adding custom controls
+### 4. Styling / Adding custom controls
 
 Qt Quick Controls 2 support different styles, and it even comes with several
 built-in styles like a Google Material style and a Microsoft Universal style.
 
 One drawback with Qt Quick Controls 2 is that application developers can only
-add custom types in QML, not in {cpp}. This makes it cumbersome for concepts
+add custom types in QML, not in C++. This makes it cumbersome for concepts
 like event handling, as is noted in the Qt documentation:
-https://doc.qt.io/qt-5/qtquickcontrols2-differences.html[Differences with Qt Quick Controls 1,role=external,window=_blank].
+[Differences with Qt Quick Controls 1](https://doc.qt.io/qt-5/qtquickcontrols2-differences.html).
 
 So an application developer who wants to add own types, as is common for medium
 to large-scale projects, will have to implement these custom types in QML.
-Since being able to use {cpp} for application logic of components seems to have been
-one reason to create Qt Quick Controls 2 (another reason being performance
-issues with Qt Quick Controls 1, see
-https://www.qt.io/blog/2015/03/31/qt-quick-controls-for-embedded[Qt Quick Controls for Embedded,role=external,window=_blank]), allowing the user to write controls in {cpp} gives the user more flexibility.
+Since being able to use C++ for application logic of components seems to have been
+one reason to create Qt Quick Controls 2 (another reason apparently being performance
+issues with Qt Quick Controls 1), allowing the user to write controls in C++ gives the user more flexibility.
 
-QSkinny allows for implementing custom types in {cpp}; also both built-in
+QSkinny allows for implementing custom types in C++; also both built-in
 components like push buttons, sliders etc. as well as custom types can be easily
-styled from {cpp}. The latter can be achieved by simply adding style
+styled from C++. The latter can be achieved by simply adding style
 descriptions in user code.
diff --git a/doc/tutorials/03-writing-your-first-application.asciidoc b/doc/tutorials/03-writing-your-first-application.md
similarity index 80%
rename from doc/tutorials/03-writing-your-first-application.asciidoc
rename to doc/tutorials/03-writing-your-first-application.md
index 4e6db4a0..0a68e777 100644
--- a/doc/tutorials/03-writing-your-first-application.asciidoc
+++ b/doc/tutorials/03-writing-your-first-application.md
@@ -1,14 +1,8 @@
----
-title: 3. Writing your first application
-layout: docs
----
+# Tutorials {#tutorials}
 
-:doctitle: 3. Writing your first application
-:notitle:
+## Writing your first application
 
-== Writing your first application
-
-=== Building the QSkinny repository
+### Building the QSkinny repository
 
 In this chapter we will write a simple QSkinny application on Linux from scratch in C++ with Qt6.
 As a prerequisite, a supported Qt6 version should be available.
@@ -20,39 +14,35 @@ Optional packages for the virtual keyboard are `libhunspell-dev libimepinyin-dev
 
 Then we can build and install QSkinny to `/opt/qskinny` with the following commands:
 
-[source,shell]
-....
+```shell
 $ git clone https://github.com/uwerat/qskinny.git # clone
 $ cd qskinny
 $ mkdir build && cd build
 $ cmake ..
 $ cmake --build .
 $ sudo cmake --install . --prefix "/opt/qskinny"
-....
-
+```
 
 Considering that you want to use a specific Qt version that is installed below "/path/to/qt"
 you have 2 options:
 
-[source,shell]
-....
+```shell
 $ cmake .. -DCMAKE_PREFIX_PATH=/path/to/qt
-....
+```
 
 or
 
-[source,shell]
-....
+```shell
 $ /path/to/qt/bin/qt-cmake ..
-....
+```
 
-=== Compiling our first app
+### Compiling our first app
 
-As a next step, we need to write our app. Let's start with a simple `main.cpp` file in a directory `myapp`:
+As a next step, we need to write our app. Let’s start with a simple `main.cpp` file in a directory `myapp`:
 
-.main.cpp
-[source]
-....
+**main.cpp**
+
+```
 #include <QskWindow.h>
 #include <QGuiApplication>
 
@@ -65,14 +55,14 @@ int main( int argc, char* argv[] )
 
     return app.exec();
 }
-....
+```
 
 For now this will just create an empty window (the `QskWindow`) without any controls.
 Next, we need to create a `CMakeLists.txt` file in our `myapp` directory.
 
-.CMakeLists.txt
-[source,cmake]
-....
+**CMakeLists.txt**
+
+```cmake
 cmake_minimum_required(VERSION 3.27)
 
 project(myapp
@@ -95,36 +85,34 @@ add_executable(myapp
 target_link_libraries(myapp PRIVATE
     Qt6::Quick
     Qsk::QSkinny)
-....
+```
 
 Now we can compile our app:
 
-[source,shell]
-....
+```shell
 $ cd myapp
 $ mkdir build && cd build
 $ cmake ../ && make
-....
+```
 
 When running myapp it needs to find the skin plugins. Setting QT_PLUGIN_PATH is one
 option ( see https://doc.qt.io/qt/deployment-plugins.html ):
 
-[source,shell]
-....
+```shell
 $ QT_PLUGIN_PATH=/opt/qskinny/plugins ./myapp
-....
+```
 
 This should show just an empty window.
 
-=== Adding UI controls
+### Adding UI controls
 
 Now that we have our app running, we can add some UI controls to it by extending the `main.cpp` file we created earlier.
 We will add some additional include directives, and then create a horizontal layout containing two push buttons.
 The layout with the two buttons will be shown in the window. Below is the complete updated source file:
 
-.main.cpp
-[source, cpp]
-....
+**main.cpp**
+
+```cpp
 #include <QskWindow.h>
 #include <QskLinearBox.h>
 #include <QskPushButton.h>
@@ -153,12 +141,12 @@ int main( int argc, char* argv[] )
 
     return app.exec();
 }
-....
+```
 
 Now the app is displaying the two buttons:
 
-image::/doc/tutorials/images/writing-first-application.png[An app showing two buttons]
+![An app showing two buttons](/doc/tutorials/images/writing-first-application.png)
 
-That's it; you just created a QSkinny application from scratch.
+That’s it; you just created a QSkinny application from scratch.
 
 For information on how the controls and layouts above behave, see the next chapters.
diff --git a/doc/tutorials/04-Layouts.asciidoc b/doc/tutorials/04-Layouts.md
similarity index 79%
rename from doc/tutorials/04-Layouts.asciidoc
rename to doc/tutorials/04-Layouts.md
index 83cfbd16..25e2ecc6 100644
--- a/doc/tutorials/04-Layouts.asciidoc
+++ b/doc/tutorials/04-Layouts.md
@@ -1,24 +1,18 @@
----
-title: 4. Layouts
-layout: docs
----
+# Tutorials {#tutorials}
 
-:doctitle: 4. Layouts
-:notitle:
-
-== Layouts
+## Layouts
 
 Layouts manage the position of UI elements on the screen, and how the
 elements react to size changes (e.g. window resize).
 
-=== Size hints
+### Size hints
 
 Size hints let the layouting code know how big UI elements are, and to
 which size they may shrink or grow.
 
 Size hints can be explicit or implicit. Explicit sizes are set by the
 user via an API call through `setExplicitSizeHint()` ("This element is
-of that size''), while implicit sizes are deduced from the elements
+of that size"), while implicit sizes are deduced from the elements
 themselves. Explicit size hints always take precedence over implicit
 ones.
 
@@ -26,8 +20,9 @@ For instance, the implicit size of a button is calculated from the
 text width (which itself depends on the font) and possibly padding and
 margins:
 
-.implicit horizontal size hint of a button
-image::/doc/tutorials/images/size-hints-calculation.png[implicit horizontal size hint of a button]
+**implicit horizontal size hint of a button**
+
+![implicit horizontal size hint of a button](/doc/tutorials/images/size-hints-calculation.png)
 
 The implicit width of a composited UI element containing a
 graphic on the left and a text on the right would be the sum of the elements’
@@ -40,14 +35,14 @@ its children. For instace a horizontal layout containing three buttons
 next to each other will calculate its implicit width by summing up the
 widths of the buttons (spacing and margins again come on top).
 
-There are three types of size hints: *Minimum*, *Preferred* and
-*Maximum*.
+There are three types of size hints: **Minimum**, **Preferred** and
+**Maximum**.
 
-* The *minimum size hint* of a UI element is used by layouting code to
+* The **minimum size hint** of a UI element is used by layouting code to
 determine how small an element can be.
-* The *preferred size hint* is the natural size of an element, and will
+* The **preferred size hint** is the natural size of an element, and will
 be used in an ideal case, meaning there is enough space available.
-* The *maximum size hint* is used by layouting code to determine how big
+* The **maximum size hint** is used by layouting code to determine how big
 an element can be.
 
 Minimum and maximum size hints of atomic controls like `QskPushButton`
@@ -59,7 +54,7 @@ Minimum and maximum sizes, i.e. the methods `minimumSize()` and
 So in total, a control can have up to 6 size hints: the three types
 described above, and each one can have an implicit and an explicit hint.
 
-==== Example
+#### Example
 
 Below is an image with an implicit size hint with a width of 91 pixels
 and a height of 39 pixels (91x39). The hint is determined by the size of
@@ -67,25 +62,26 @@ the text (71x19 pixels) plus margins (10 pixels each for top, right,
 bottom, left). We don’t need to set a size hint explicitly, the control
 will be rendered correctly with the implicit size hint:
 
-[source]
-....
+```
 auto* label1 = new QskTextLabel( "control 1" );
 label1->setMargins( 10 );
 label1->setBackgroundColor( Qt::magenta );
-....
+```
 
-.control without explicit size hint
-image::/doc/tutorials/images/size-hints-1.png[Image without explicit size hint]
+**control without explicit size hint**
+
+![Image without explicit size hint](/doc/tutorials/images/size-hints-1.png)
 
 If we set an explicit size hint of 150x60 pixels ourselves for the
 preferred size, the control will be rendered differently:
 
-....
+```
 label1->setExplicitSizeHint( Qt::PreferredSize, { 150, 60 } );
-....
+```
 
-.control with explicit size hint
-image::/doc/tutorials/images/size-hints-2.png[Image with explicit size hint]
+**control with explicit size hint**
+
+![Image with explicit size hint](/doc/tutorials/images/size-hints-2.png)
 
 When dealing with standard controls or layouts, the size hints don’t
 need to be specified explicitly, as it can be deduced from its standard
@@ -94,7 +90,7 @@ values, as seen in the example above.
 The actual size of a UI element also depends on its size policy, see the
 next topic.
 
-=== Size policies
+### Size policies
 
 Size policies define the way UI elements can change their size depending
 on the available space. Imagine a UI with a top bar and a main content
@@ -109,7 +105,6 @@ The size policies of QSkinny correspond to the
 *https://doc.qt.io/qt-5/qsizepolicy.html#Policy-enum[size policies from
 QtWidgets]*:
 
-[width="100%",cols="50%,50%",options="header",]
 |=======================================================================
 |`QskSizePolicy::Policy` |description
 |`Fixed` |The control has a fixed size and can neither grow nor shrink.
@@ -154,21 +149,20 @@ constraint, and it should get as much space as possible.
 |=======================================================================
 
 All the `Constrained*` policies correspond to Qt’s
-https://doc.qt.io/qt-5/qsizepolicy.html#hasHeightForWidth[QSizePolicy::hasHeightForWidth()]
+[QSizePolicy::hasHeightForWidth()](https://doc.qt.io/qt-5/qsizepolicy.html#hasHeightForWidth)
 or
-https://doc.qt.io/qt-5/qsizepolicy.html#hasWidthForHeight[QSizePolicy::hasWidthForHeight()]
+[QSizePolicy::hasWidthForHeight()](https://doc.qt.io/qt-5/qsizepolicy.html#hasWidthForHeight)
 flag. E.g. if a control has a horizontal size policy of `Constrained`
 and a vertical size policy of `Fixed`, it will call `widthForHeight()`
 to determine the width that corresponds to the height.
 
-==== Example
+#### Example
 
 Below is an example of two buttons with different size policies. In this
 case only the horizontal size policies are considered; the vertical size
 policies behave correspondingly.
 
-[source]
-....
+```
 auto horizontalBox = new QskLinearBox( Qt::Horizontal );
 
 auto* label1 = new QskTextLabel( "size policy: fixed" );
@@ -179,53 +173,56 @@ auto* label2 = new QskTextLabel( "size policy: minimum" );
 label2->setSizePolicy( Qt::Horizontal, QskSizePolicy::Minimum );
 horizontalBox->addItem( label2 );
 ...
-....
+```
 
 By default the width of the buttons is determined by its text plus its
 margins:
 
-.Size policies with preferred size
-image::/doc/tutorials/images/size-policies-horizontal-minimum-1.png[Fixed vs. Minimum size policy]
+**Size policies with preferred size**
+
+![Fixed vs. Minimum size policy](/doc/tutorials/images/size-policies-horizontal-minimum-1.png)
 
 After growing the window horizontally, the button with the Fixed
 horizontal size policy keeps its width, while the button with the
 Minimum policy will grow:
 
-.Size policies when increasing window width
-image::/doc/tutorials/images/size-policies-horizontal-minimum-2.png[Fixed vs. Minimum size policy]
+**Size policies when increasing window width**
+
+![Fixed vs. Minimum size policy](/doc/tutorials/images/size-policies-horizontal-minimum-2.png)
 
 When shrinking the window below its original size, both buttons stay
 with their width: The one on the left because of its `Fixed` size policy,
 and the one on the right because it won’t shrink below its original size
 due to the `Minimum` size policy.
 
-.Size policies when shrinking window width
-image::/doc/tutorials/images/size-policies-horizontal-minimum-3.png[Fixed vs. Minimum size policy]
+**Size policies when shrinking window width**
+
+![Fixed vs. Minimum size policy](/doc/tutorials/images/size-policies-horizontal-minimum-3.png)
 
 If we change the policy of the right button to `Preferred`, it will shrink
 below its original size (even though the text is too wide now):
 
-....
+```
 label2->setSizePolicy( Qt::Horizontal, QskSizePolicy::Preferred );
 label2->setText( "size policy: preferred" );
-....
+```
 
-.Size policies when changing to preferred size policy
-image::/doc/tutorials/images/size-policies-horizontal-minimum-4.png[Fixed vs. Minimum size policy]
+**Size policies when changing to preferred size policy**
 
-=== Types of layouts
+![Fixed vs. Minimum size policy](/doc/tutorials/images/size-policies-horizontal-minimum-4.png)
+
+### Types of layouts
 
 There are different types of layouts that can group UI elements
 together. Internally, layouts use the `layoutRect()` method to determine
 the available space to place its children.
 
-==== Linear layouts (QskLinearBox)
+#### Linear layouts (QskLinearBox)
 
 A linear layout can group elements either horizontally or vertically, as
 in the images below.
 
-[source]
-....
+```
 auto horizontalBox = new QskLinearBox( Qt::Horizontal );
 
 auto* label1 = new QskTextLabel( "control 1" );
@@ -237,13 +234,13 @@ horizontalBox->addItem( label2 );
 auto* label3 = new QskTextLabel( "control 3" );
 horizontalBox->addItem( label3 );
 ...
-....
+```
 
-.Horizontal layout
-image::/doc/tutorials/images/layout-horizontal.png[Horizontal layout]
+**Horizontal layout**
 
-[source]
-....
+![Horizontal layout](/doc/tutorials/images/layout-horizontal.png)
+
+```
 auto verticalBox = new QskLinearBox( Qt::Vertical );
 
 auto* label1 = new QskTextLabel( "control 1" );
@@ -255,18 +252,18 @@ verticalBox->addItem( label2 );
 auto* label3 = new QskTextLabel( "control 3" );
 verticalBox->addItem( label3 );
 ...
-....
+```
 
-.Vertical layout
-image::/doc/tutorials/images/layout-vertical.png[Vertical layout]
+**Vertical layout**
 
-==== Grid layouts (QskGridBox)
+![Vertical layout](/doc/tutorials/images/layout-vertical.png)
+
+#### Grid layouts (QskGridBox)
 
 Grid layouts are like linear layouts, but 2 dimensional, and support
 laying out UI controls in a grid, including spanning columns and rows.
 
-[source]
-....
+```
 auto* gridBox = new QskGridBox;
 
 auto* label1 = new QskTextLabel( "control 1" );
@@ -289,19 +286,19 @@ gridBox->addItem( label6, 2, 0 );
 
 auto* label7 = new QskTextLabel( "control 7" );
 gridBox->addItem( label7, 2, 1, 1, 2 );
-....
+```
 
-.Grid layout
-image::/doc/tutorials/images/layout-grid.png[Grid layout]
+**Grid layout**
 
-==== Stack layouts (QskStackBox)
+![Grid layout](/doc/tutorials/images/layout-grid.png)
+
+#### Stack layouts (QskStackBox)
 
 Stack layouts allow for items to be arranged on top of each other.
 Usually there is one current (visible) item, while the rest of the items
 are hidden below the current one:
 
-[source]
-....
+```
 auto* stackBox = new QskStackBox;
 
 auto* label1 = new QskTextLabel( "control 1" );
@@ -318,25 +315,27 @@ stackBox->addItem( label3 );
 
 stackBox->setCurrentIndex( 2 );
 ...
-....
+```
 
-.Stack layout (symbolized)
-image::/doc/tutorials/images/layout-stack.png[Stack layout]
+**Stack layout (symbolized)**
+
+![Stack layout](/doc/tutorials/images/layout-stack.png)
 
 In this example, "control 3" is stacked on top of the blue and the
 cyan control. Controls in a stacked layout can be of different sizes.
 
-NOTE: The image above is just for illustrating purposes. In practice
+**📌 NOTE**\
+The image above is just for illustrating purposes. In practice
 the topmost control ("control 3" here) is completely covering the ones
 below it.
 
-==== QskControl::autoLayoutChildren()
+#### QskControl::autoLayoutChildren()
 
 When the `QskControl::autoLayoutChildren()` flag is set, the control will
 recalculate the geometry of its children whenever the item is updating
 its layout.
 
-=== Stretch factors
+### Stretch factors
 
 Stretch factors allow layouts to keep a size ratio for their elements.
 Let’s say a horizontal layout contains two elements, and when filling up
@@ -347,8 +346,7 @@ factor of 1 and the second element a factor of 2.
 Stretch factors are set on the layout rather than on the controls
 itself:
 
-[source]
-....
+```
 auto horizontalBox = new QskLinearBox( Qt::Horizontal );
 
 auto* label1 = new QskTextLabel( "stretch factor 1" );
@@ -360,45 +358,48 @@ horizontalBox->addItem( label2 );
 horizontalBox->setStretchFactor( label2, 2 );
 
 ...
-....
+```
 
 When the layout has all the space it needs (but not more), both elements
 are rendered with their preferred size:
 
-.Stretch factors with preferred size
-image::/doc/tutorials/images/stretch-factors-1.png[Stretch factors preferred size]
+**Stretch factors with preferred size**
+
+![Stretch factors preferred size](/doc/tutorials/images/stretch-factors-1.png)
 
 When the layout gets more width, the stretch factors come into play:
 
-.A stretch factor of 1:2
-image::/doc/tutorials/images/stretch-factors-2.png[Stretch factors increasing width]
+**A stretch factor of 1:2**
+
+![Stretch factors increasing width](/doc/tutorials/images/stretch-factors-2.png)
 
 No matter how wide the layout is, the aspect ratio of 1:2 will always be
 kept, meaning that the label on the left will get 33% of the space, and
 the label on the right 67%:
 
-.A stretch factor of 1:2 with different widths
-image::/doc/tutorials/images/stretch-factors-3.png[Stretch factors even more width]
+**A stretch factor of 1:2 with different widths**
+
+![Stretch factors even more width](/doc/tutorials/images/stretch-factors-3.png)
 
 Stretch factors in QSkinny are the same as in the Qt Graphics View
 Framework, see
 https://doc.qt.io/qt-5/qgraphicslinearlayout.html#stretch-factor-in-qgraphicslinearlayout[Stretch
 Factor in QGraphicsLinearLayout].
 
-=== Nesting layouts
+### Nesting layouts
 
 In a real-world application it is typical to nest several layouts in
 each other. The example below depicts a UI with a top bar and menu items
 on the left:
 
-.A UI with nested layouts
-image::/doc/tutorials/images/nesting-layouts.png[Nested layouts]
+**A UI with nested layouts**
+
+![Nested layouts](/doc/tutorials/images/nesting-layouts.png)
 
 The code to produce the above UI could look like this (setting colors
 etc. omitted for brevity):
 
-[source]
-....
+```
 auto* outerBox = new QskLinearBox( Qt::Vertical );
 
 auto* topBar = new QskLinearBox( Qt::Horizontal, outerBox );
@@ -417,7 +418,7 @@ auto* menuLabel3 = new QskTextLabel( "menu 3", menuBox );
 
 auto* mainText = new QskTextLabel( "here main area", mainBox );
 ...
-....
+```
 
 Here we have an outer vertical layout which divides the content into a
 top bar and a main box. The top bar itself consists of a horizontal
@@ -427,10 +428,10 @@ with the menu buttons is again a vertical layout.
 
 The following diagram makes the layouts visible:
 
-.The layout structure of the UI
-image::/doc/tutorials/images/nesting-layouts-architecture.png[Nested layouts architecture]
+**The layout structure of the UI**
 
-=== Anchoring in QSkinny
+![Nested layouts architecture](/doc/tutorials/images/nesting-layouts-architecture.png)
+
+### Anchoring in QSkinny
 
 TODO
-
diff --git a/doc/tutorials/05-Skins.asciidoc b/doc/tutorials/05-Skins.md
similarity index 81%
rename from doc/tutorials/05-Skins.asciidoc
rename to doc/tutorials/05-Skins.md
index 7cba03ea..c9419b91 100644
--- a/doc/tutorials/05-Skins.asciidoc
+++ b/doc/tutorials/05-Skins.md
@@ -1,33 +1,27 @@
----
-title: 5. Skins
-layout: docs
----
+# Tutorials {#tutorials}
 
-:doctitle: 5. Skins
-:notitle:
-
-== Skins, Skin hints and Skinlets
+## Skins, Skin hints and Skinlets
 
 Skins, Skin hints and Skinlets allow the user to define how specific
 controls looke like. Controls are drawn on the screen by the
 skinlet, and therefore it will read information from both the control
 itself as well as read the skin hints from the skin:
 
-.Skinlets query the control and the skin
-image::/doc/tutorials/images/skins-1.png[Styling controls]
+**Skinlets query the control and the skin**
+
+![Styling controls](/doc/tutorials/images/skins-1.png)
 
 For instance, a button skinlet will read the margins from the skin and
 the text to render from the button.
 
-=== Skins
+### Skins
 
 Skins are a way to define a look and feel for a whole set of UI
 controls, e.g. a night time vs. day time skin, skins for different
 brands or an Android Material skin. They contain all kinds of properties
 (i.e. skin hints) like colors, margins, fonts and more.
 
-[source]
-....
+```
 class MySkin : public QskSkin
 {
 
@@ -37,19 +31,21 @@ public:
         // here define the skin with skin hints
     }
 };
-....
+```
 
 The example below shows different implementations for a push button: One
 has a traditional desktop skin, the other is a flat button with a skin
 often found in mobile devices.
 
-.desktop style button
-image::/doc/tutorials/images/skinlets-button-1.png[desktop style button]
+**desktop style button**
 
-.flat button
-image::/doc/tutorials/images/skinlets-button-2.png[flat button]
+![desktop style button](/doc/tutorials/images/skinlets-button-1.png)
 
-=== Skin hints
+**flat button**
+
+![flat button](/doc/tutorials/images/skinlets-button-2.png)
+
+### Skin hints
 
 Each instance of a button will have unique properties like its text or
 icon file name, but all buttons will have common properties like the
@@ -69,8 +65,7 @@ Extending the `MySkin` example from above, here is an example of some
 skin hints for a push button, setting the padding to 10 pixels, the
 background color to magenta and the text color to black:
 
-[source]
-....
+```
 class MySkin : public QskSkin
 {
 
@@ -82,10 +77,11 @@ public:
         setColor( QskPushButton::Text, Qt::black );
     }
 };
-....
+```
 
-.A button styled with skin hints
-image::/doc/tutorials/images/skin-hints.png[Button with skin hints]
+**A button styled with skin hints**
+
+![Button with skin hints](/doc/tutorials/images/skin-hints.png)
 
 When writing a new skin, a developer needs to know which hints to set
 for which control. This usually depends on the control itself; however,
@@ -93,31 +89,30 @@ since usually controls are broken down into the three primitives box,
 text and graphic, the methods for rendering each of them will take the
 following skin hints into account:
 
-[cols=",",options="header",]
 |=======================================================================
 |Primitive |Skin hint from QskAspect
-|Text |`Alignment` +
-`Color` +
-`TextColor` +
-`StyleColor` +
-`LinkColor` +
-`Style` +
+|Text |`Alignment`\
+`Color`\
+`TextColor`\
+`StyleColor`\
+`LinkColor`\
+`Style`\
 `FontRole`
 
-|Graphic |`Alignment` +
+|Graphic |`Alignment`\
 `GraphicRole`
 
-|Box | `Margin` +
-`Metric` \| `Border` +
-`Color` \| `Border` +
-`Color` +
+|Box | `Margin`\
+`Metric` \| `Border`\
+`Color` \| `Border`\
+`Color`\
 `Metric` \| `Shape`
 |=======================================================================
 
 Some special cases exist where elements other than the primitives above
 are used.
 
-==== States and animations
+#### States and animations
 
 Skin hints can also depend on the state a control is in: Buttons for
 instance can be in a `Pressed` or `Hovered` state. For such cases, skin
@@ -135,8 +130,7 @@ button, there will be a smooth animation from magenta to cyan
 interpolating between the colors. Without the `setAnimation()` call, the
 button would just switch to magenta when hovered right away.
 
-[source]
-....
+```
 class MySkin : public QskSkin
 {
 
@@ -151,39 +145,41 @@ public:
         setAnimation( QskPushButton::Panel | QskAspect::Color, 1000 );
     }
 };
-....
+```
 
-.button in normal state
-image::/doc/tutorials/images/skin-hints-states-1.png[button in normal state]
+**button in normal state**
 
-.button in hovered state
-image::/doc/tutorials/images/skin-hints-states-2.png[button in hovered state]
+![button in normal state](/doc/tutorials/images/skin-hints-states-1.png)
 
-==== Local skin hints
+**button in hovered state**
+
+![button in hovered state](/doc/tutorials/images/skin-hints-states-2.png)
+
+#### Local skin hints
 
 It is possible to set local skin hints on specific controls to override
 skin-wide settings:
 
-[source]
-....
+```
 auto* label1 = new QskTextLabel( "control 1" );
 label1->setMargins( 20 );
 label1->setBackgroundColor( Qt::blue );
-....
+```
 
 In general it is recommended to set the skin hints in the skin rather
 than on the control locally, in order to separate the style from the
 implementation, and to allow switching between skins. How to write
 controls that are themable is explained in the section about
-link:Writing-own-controls.html[writing own controls].
+[writing own controls](Writing-own-controls.html).
 
 Taking animations and local skin hints into account, the architecture
 diagram now looks like this:
 
-.Skinlets can also read from local skinlets and animators
-image::/doc/tutorials/images/skins-2.png[Animators and local skin hints]
+**Skinlets can also read from local skinlets and animators**
 
-=== Skinlets
+![Animators and local skin hints](/doc/tutorials/images/skins-2.png)
+
+### Skinlets
 
 A skinlet is in charge of drawing a control on the screen, similar to a
 Delegate in QML. It will read all the hints it needs from either the
@@ -204,19 +200,20 @@ QSkinny already contains implementations of many common controls like
 text labels, buttons and so on. However, some custom controls might
 need to be written from scratch, including the skinlet; for an
 explanation on how to do this, see the example of
-link:Writing-own-controls.html[writing own controls].
+[writing own controls](Writing-own-controls.html).
 
 For a closer look at how the skinlet draws the controls in the scene
-graph, see link:scene-graph.html[scene graph representations of controls].
+graph, see [scene graph representations of controls](scene-graph.html).
 
 Of course each app has different controls and therefore there are also
 different skinlets, so a more complete version of the architecture
 diagram looks like this:
 
-.There is one skinlet for each atomic control
-image::/doc/tutorials/images/skins-3.png[Animators and local skin hints]
+**There is one skinlet for each atomic control**
 
-=== Skin factories and switching between skins
+![Animators and local skin hints](/doc/tutorials/images/skins-3.png)
+
+### Skin factories and switching between skins
 
 Skins are usually not created by the user directly, but by a skin
 factory. Such a factory keeps track of the skins registered in the
@@ -226,8 +223,7 @@ during application lifetime.
 When having two skins called `MySkin` and `OtherSkin` in an app, the
 corresponding skin factory might look like this:
 
-[source]
-....
+```
 class MySkinFactory : public QskSkinFactory
 {
 
@@ -250,13 +246,12 @@ public:
         return nullptr;
     }
 };
-....
+```
 
 That skin factory has to be registered during app start; it is also a
 good idea to set a default skin right away:
 
-[source]
-....
+```
 int main( int argc, char* argv[] )
 {
     auto* skinFactory = new MySkinFactory;
@@ -272,14 +267,13 @@ int main( int argc, char* argv[] )
 
     return app.exec();
 }
-....
+```
 
 Now we can define the `OtherSkin` and define different skin hints for
 e.g. push buttons. Here we define the background color and padding to be
 different; also we configure buttons to have a blue border:
 
-[source]
-....
+```
 class OtherSkin : public QskSkin
 {
 
@@ -292,14 +286,15 @@ public:
         setBoxBorderMetrics( QskPushButton::Panel, 1 );
     }
 };
-....
+```
 
 Switching between skins will change the look of `QskPushButton`
 instances:
 
-.button in `MySkin` (as above)
-image::/doc/tutorials/images/skin-hints-states-1.png[button in normal state]
+**button in `MySkin` (as above)**
 
-.button in `OtherSkin`
-image::/doc/tutorials/images/skin-factory.png[Styling controls]
+![button in normal state](/doc/tutorials/images/skin-hints-states-1.png)
 
+**button in `OtherSkin`**
+
+![Styling controls](/doc/tutorials/images/skin-factory.png)
diff --git a/doc/tutorials/06-scalable-graphics.asciidoc b/doc/tutorials/06-scalable-graphics.md
similarity index 75%
rename from doc/tutorials/06-scalable-graphics.asciidoc
rename to doc/tutorials/06-scalable-graphics.md
index c0297aa4..60765455 100644
--- a/doc/tutorials/06-scalable-graphics.asciidoc
+++ b/doc/tutorials/06-scalable-graphics.md
@@ -1,12 +1,6 @@
----
-title: 6. (Scalable) graphics
-layout: docs
----
+# Tutorials {#tutorials}
 
-:doctitle: 6. (Scalable) graphics
-:notitle:
-
-== (Scalable) graphics
+## (Scalable) graphics
 
 QSkinny offers support for scalable graphics, i.e. rendering SVGs that
 adapt to a specific size. This means that when a graphic is embedded in
@@ -15,8 +9,7 @@ shrinking, while still maintaining a correct aspect ratio.
 
 Imagine the following code, which produces the image depicted below:
 
-[source]
-....
+```
 auto horizontalBox = new QskLinearBox( Qt::Horizontal );
 horizontalBox->setPreferredSize( { 200, 75 } );
 
@@ -30,19 +23,22 @@ QskGraphic graphic2 = QskGraphic::fromImage( image2 );
 auto* label2 = new QskGraphicLabel( graphic2, horizontalBox );
 label2->setSizePolicy( QskSizePolicy::ConstrainedPreferred, QskSizePolicy::Expanding );
 ...
-....
+```
 
-.graphics with preferred size
-image::/doc/tutorials/images/scalable-graphics-1.png[Scalable graphics default]
+**graphics with preferred size**
+
+![Scalable graphics default](/doc/tutorials/images/scalable-graphics-1.png)
 
 When resizing the window, the graphics will scale according to the size
 available in the layout:
 
-.graphics bounded by width
-image::/doc/tutorials/images/scalable-graphics-2.png[Scalable graphics bounded by width]
+**graphics bounded by width**
 
-.graphics bounded by height
-image::/doc/tutorials/images/scalable-graphics-3.png[Scalable graphics bounded by height]
+![Scalable graphics bounded by width](/doc/tutorials/images/scalable-graphics-2.png)
+
+**graphics bounded by height**
+
+![Scalable graphics bounded by height](/doc/tutorials/images/scalable-graphics-3.png)
 
 Since we set the horizontal size policy of the graphics to
 `ConstrainedPreferred`, the scaling is done through QskGraphic’s
@@ -53,10 +49,8 @@ one to e.g. `Expanding`, the layout would have queried the
 
 Of course non-scalable graphics like PNGs and JPGs are also supported:
 
-[source]
-....
+```
 QImage image( "background.jpg" );
 QskGraphic graphic = QskGraphic::fromImage( image );
 ...
-....
-
+```
diff --git a/doc/tutorials/07-parents-and-parent-items.asciidoc b/doc/tutorials/07-parents-and-parent-items.asciidoc
deleted file mode 100644
index 61d3e7d0..00000000
--- a/doc/tutorials/07-parents-and-parent-items.asciidoc
+++ /dev/null
@@ -1,191 +0,0 @@
----
-title: 7. Parents and parent items
-layout: docs
----
-
-:doctitle: 7. Parents and parent items
-:notitle:
-
-== Parents and parent items
-
-Creating an app with QSkinny consists of creating controls, putting them
-into layouts and nesting layouts and controls inside each other. The
-nesting already creates some sort of a hierarchy in the app, see the
-"Nesting layouts" section in the link:Layouts.html[layouts page]. In
-more general terms, all controls are part of several hierarchies:
-
-* The *object tree*. This is a tree of `QObject` instances which manages
-lifetime: Objects created with a parent will get deleted whenever their
-parent is deleted. For more information, see the Qt documentation on
-https://doc.qt.io/qt-5/objecttrees.html[Object Trees & Ownership].
-* The *item tree*. This is a tree of items displayed on the screen,
-i.e. `QQuickItem` instances. Qt will traverse the item tree when
-rendering items on the screen. The positioning of an item depends on its
-parent item, e.g. layouts will position their child items according to
-certain policies. In addition, visual items will inherit properties from
-its parent item like visibility or opacity. The item tree is often
-similar to the object tree, but not necessarily: Instances of
-`QQuickItem` can have a parent item set, but have another parent, or no
-parent at all. See also the Qt documentation on
-https://doc.qt.io/qt-5/qtquick-visualcanvas-visualparent.html[Concepts -
-Visual Parent in Qt Quick].
-* The *scene graph*. The scene graph contains a representation of
-graphic primitives like rectangles, textures (i.e. images) and text, to
-allow efficient rendering on the screen with OpenGL or other backends.
-This is described in more details in link:scene-graph.html[scene graph
-representations of controls].
-
-=== Example
-
-Let’s look at the "Nesting layouts" example from the
-link:Layouts.html[layouts documentation]. The UI looks like this:
-
-.UI with nested layouts
-image::/doc/tutorials/images/nesting-layouts.png[Nested layouts]
-
-The code for this UI is below:
-
-[source]
-....
-auto* outerBox = new QskLinearBox( Qt::Vertical );
-
-auto* topBar = new QskLinearBox( Qt::Horizontal, outerBox );
-
-auto* topLabel1 = new QskTextLabel( "top bar label 1", topBar );
-auto* topLabel2 = new QskTextLabel( "top bar label 2", topBar );
-auto* topLabel3 = new QskTextLabel( "top bar label 3", topBar );
-
-auto* mainBox = new QskLinearBox( Qt::Horizontal, outerBox );
-
-auto* menuBox = new QskLinearBox( Qt::Vertical, mainBox );
-
-auto* menuLabel1 = new QskTextLabel( "menu 1", menuBox );
-auto* menuLabel2 = new QskTextLabel( "menu 2", menuBox );
-auto* menuLabel3 = new QskTextLabel( "menu 3", menuBox );
-
-auto* mainText = new QskTextLabel( "here main area", mainBox );
-
-QskWindow window;
-window.addItem( outerBox );
-window.show();
-....
-
-==== Object tree
-
-In the example above, when we created a new element, we always passed
-the `QObject` parent as an argument to the constructor, which is good
-practice. We do that for instance in this line:
-
-[source]
-....
-auto* topLabel1 = new QskTextLabel( "top bar label 1", topBar );
-....
-
-This makes sure `topBar` is a parent of `topLabel1`. It means that when
-`topBar` is deleted, it will automatically delete `topLabel1`, because
-the latter is a child of the `topBar`.
-
-Below is an image of the object tree, i.e. the `QObject` parent-child
-relationship. The `QskWindow` is hereby the parent of the
-`QQuickRootItem`, which itself is the parent of the `outer box`, and so
-on. For information on how to obtain this tree, see
-https://doc.qt.io/qt-5/qobject.html#dumpObjectTree[QObject::dumpObjectTree()].
-
-.QObject tree (and item tree) of the nested layouts UI
-image::/doc/tutorials/images/object-hierarchy.png[QObject hierarchy]
-
-==== Item tree
-
-The Item tree for the example above is identical to the object tree. As
-described, we always pass the parent object in the constructor:
-
-[source]
-....
-auto* topLabel1 = new QskTextLabel( "top bar label 1", topBar );
-....
-
-The line above will (in addition to the setting the parent) also ensure
-that `topBar` will be a *parent item* of `topLabel1`; this is done by
-the `QQuickItem` constructor.
-
-Even if we had not passed the parent in the constructor, we could still
-add the label to the `topBar` via an explicit call:
-
-[source]
-....
-auto* topLabel1 = new QskTextLabel( "top bar label 1" );
-topBar->addItem( topLabel1 );
-....
-
-The call to `addItem()` above sets the parent item of `topLabel1` to
-`topBar` and thus the latter will display it as one of its children. In
-this case it would also set the parent, because the `topLabel1` does not
-have one yet. In other words, setting a parent item will also set the
-parent *if* the parent is null.
-
-So since the `topBar` is a parent item of `topLabel1`, it means that
-`topLabel1` will inherit settings like visibility and opacity from
-`topBar`. For instance, if we set the the visibility of the `topBar` to
-false, all its child items will be invisible as well (which in this case
-would be all top bar labels). If we set the opacity to 0.2, all its
-child items will be almost transparent:
-
-[source]
-....
-topBar->setOpacity( 0.2 );
-....
-
-.Changing opacity of an item will affect all its child items
-image::/doc/tutorials/images/nesting-layouts-item-tree-1.png[Changing the item tree]
-
-==== Difference in object trees and item trees
-
-As an example for when the object tree and item tree differ, let’s
-decide to add a bottom bar to our UI and move our `topLabel1` from the
-top bar to the bottom bar. This is easy:
-
-[source]
-....
-auto* bottomBar = new QskLinearBox( Qt::Horizontal, outerBox );
-topLabel1->setParentItem( bottomBar );
-....
-
-.Moving a label from the top bar to the bottom bar
-image::/doc/tutorials/images/nesting-layouts-item-tree-2.png[Moving a label to the bottom bar]
-
-Now we decide to get rid of our top bar altogether:
-
-[source]
-....
-topBar->deleteLater();
-....
-
-This will also delete our label from the bottom bar:
-
-.Deleting the top bar will delete all its children
-image::/doc/tutorials/images/nesting-layouts-item-tree-3.png[Deleting the top bar]
-
-The reason why the label from the bottom bar was also deleted is that
-with the call to `setParentItem()` above we set a new parent item; the
-parent, however, was still `topBar` (the call to `setParentItem()` did
-not change the parent, because it was not null). So when the `topBar`
-was deleted, it deleted all of its children, including the moved label
-`topLabel1`.
-
-After we moved the label to the bottom bar, the object tree was
-different from the item tree, hence we got a surprising result when
-deleting the top bar. It is a good idea to try to keep the trees the
-same, and be aware of the existence of both of them.
-
-If we reparent our label to the bottom bar before deleting the top bar,
-we get the desired effect:
-
-[source]
-....
-topLabel1->setParent( bottomBar );
-topLabel1->setParentItem( bottomBar );
-topBar->deleteLater();
-....
-
-.Reparenting the label will keep it alive when deleting the top bar
-image::/doc/tutorials/images/nesting-layouts-item-tree-4.png[Reparenting the item]
diff --git a/doc/tutorials/08-qskinny-and-qml.asciidoc b/doc/tutorials/08-qskinny-and-qml.md
similarity index 75%
rename from doc/tutorials/08-qskinny-and-qml.asciidoc
rename to doc/tutorials/08-qskinny-and-qml.md
index 577d94ab..5984436e 100644
--- a/doc/tutorials/08-qskinny-and-qml.asciidoc
+++ b/doc/tutorials/08-qskinny-and-qml.md
@@ -1,12 +1,6 @@
----
-title: 8. Using QSkinny and QML
-layout: docs
----
+# Tutorials {#tutorials}
 
-:doctitle: 8. Using QSkinny and QML
-:notitle:
-
-== QSkinny - Using QSkinny and QML
+## QSkinny - Using QSkinny and QML
 
 Combining QSkinny and QML is possible: Since both QML elements and
 QSkinny controls derive from `QQuickItem`, they can be combined and
@@ -18,31 +12,29 @@ When using a QSkinny control, all the methods exposed as either properties,
 slots or invokables can be used in QML. For example, the QSkinny control
 `QskLinearBox` defines the following properties:
 
-.CMakeLists.txt
-[source,cmake]
-....
+**CMakeLists.txt**
+
+```cmake
 target_link_libraries(myapp PRIVATE 
     ...
     Qsk::QmlExport)
 ...
-....
+```
 
-[source,cpp]
-....
+```cpp
 class QSK_EXPORT QskLinearBox : public QskIndexedLayoutBox
 {
     Q_PROPERTY( Qt::Orientation orientation READ orientation WRITE setOrientation NOTIFY orientationChanged FINAL )
     Q_PROPERTY( qreal spacing READ spacing WRITE setSpacing RESET resetSpacing NOTIFY spacingChanged FINAL )
     ...
 };
-....
+```
 
 The `QskLinearBox` class is registered to QML as `Qsk.LinearBox` via
 Qt’s `qmlRegisterType`, so the exposed properties `orientation` and
 `spacing` can be used like this:
 
-[source]
-....
+```
 Qsk.LinearBox
 {
     orientation: Qt.Horizontal
@@ -51,12 +43,13 @@ Qsk.LinearBox
     // here define elements inside the box
     ...
 }
-....
+```
 
 The full Buttons example is depicted below.
 
-.The buttons example shows how to mix QSkinny and QML
-image::/doc/tutorials/images/buttons-example.png[Buttons example]
+**The buttons example shows how to mix QSkinny and QML**
+
+![Buttons example](/doc/tutorials/images/buttons-example.png)
 
 For more information on using C++ classes from QML, see the article about exposing attributes of {cpp} types to QML in the
-https://doc.qt.io/qt-5/qtqml-cppintegration-exposecppattributes.html[Qt documentation].
+[Qt documentation](https://doc.qt.io/qt-5/qtqml-cppintegration-exposecppattributes.html).
diff --git a/doc/tutorials/09-writing-own-controls.asciidoc b/doc/tutorials/09-writing-own-controls.md
similarity index 88%
rename from doc/tutorials/09-writing-own-controls.asciidoc
rename to doc/tutorials/09-writing-own-controls.md
index 94f65c0b..1d628f90 100644
--- a/doc/tutorials/09-writing-own-controls.asciidoc
+++ b/doc/tutorials/09-writing-own-controls.md
@@ -1,26 +1,19 @@
----
-title: 9. Writing own controls
-layout: docs
----
+# Tutorials {#tutorials}
 
-:doctitle: 9. Writing own controls
-:notitle:
-
-== Writing own controls
+## Writing own controls
 
 Writing own controls is either done by subclassing or compositing an
 existing displayable control like `QskTextLabel`, or by writing a
 completely new class including a skinlet, which is typically derived
 directly from `QskControl`.
 
-=== Subclassing existing controls
+### Subclassing existing controls
 
 Let’s say an app is displaying a text label with a specific style at
 several different places, then it makes sense to subclass `QskTextLabel`
 and set the needed properties like font size etc. in the derived class:
 
-[source]
-....
+```
 class TextLabel : public QskTextLabel
 {
 
@@ -33,15 +26,16 @@ public:
         setBackgroundColor( Qt::cyan );
     }
 };
-....
+```
 
-.A subclassed control with local skin hints
-image::/doc/tutorials/images/subclassing-existing-controls.png[Subclassing existing controls]
+**A subclassed control with local skin hints**
+
+![Subclassing existing controls](/doc/tutorials/images/subclassing-existing-controls.png)
 
 Then there is no need to set the margins and background color for every
 instance of the custom text label.
 
-=== Making custom classes skinnable
+### Making custom classes skinnable
 
 To make custom classes like the `TextLabel` class above skinnable, we
 need to define our own subcontrols and style them in our skin, in
@@ -51,8 +45,7 @@ generic `QskTextLabel`, we need to define our own subcontrols and
 substitute the generic subcontrols for them in an overriden method
 `effectiveSubcontrol()`:
 
-[source]
-....
+```
 class TextLabel : public QskTextLabel
 {
     QSK_SUBCONTROLS( Panel )
@@ -70,7 +63,7 @@ class TextLabel : public QskTextLabel
     }
     ...
 }
-....
+```
 
 When the skinlet is drawing a `TextLabel` instance, it queries it for
 its subcontrols through `effectiveSubcontrol()` in order to style them
@@ -79,8 +72,7 @@ properly. Now that we substitute the `QskTextLabel::Panel` for our
 need to set the local skin hints in the constructor of `TextLabel`
 anymore.
 
-[source]
-....
+```
 class MySkin : public QskSkin
 {
 
@@ -91,10 +83,11 @@ public:
         setMargins( TextLabel::Panel | QskAspect::Padding, 15 );
     }
 };
-....
+```
 
-.A subclassed control with skin hints defined in the skin
-image::/doc/tutorials/images/subclassing-existing-controls.png[Subclassing existing controls]
+**A subclassed control with skin hints defined in the skin**
+
+![Subclassing existing controls](/doc/tutorials/images/subclassing-existing-controls.png)
 
 The styling described above has the same effect as in the simpler
 example, but now the `TextLabel` control can be given a different style
@@ -104,14 +97,13 @@ In our class we only set a custom skin hint for the panel, but as
 `QskTextLabel` also has a `Text` subcontrol, we could of course also
 define our own one for the text.
 
-=== Compositing controls
+### Compositing controls
 
 Controls can also be composited; e.g. when writing a class with a text
 label on the left and a graphic on the right side, it could look like
 this:
 
-[source]
-....
+```
 class TextAndGraphic : public QskLinearBox
 {
 
@@ -139,34 +131,33 @@ private:
     QskTextLabel* m_textLabel;
     QskGraphicLabel* m_graphicLabel;
 };
-....
+```
 
 This allows for easy instantiation of the class with a text and a file
 name for the graphic:
 
-[source]
-....
+```
 auto* textAndGraphic = new TextAndGraphic( "Text", "cloud" );
-....
+```
 
-.A composited control
-image::/doc/tutorials/images/compositing-controls.png[Compositing controls]
+**A composited control**
 
-=== Writing controls with a skinlet
+![Compositing controls](/doc/tutorials/images/compositing-controls.png)
+
+### Writing controls with a skinlet
 
 QSkinny already comes with controls like text labels, list views,
 buttons etc. When there is a completely new control to be written that
 cannot be subclassed or composited, the skinlet for the class needs to
 be implemented as well.
 
-==== Writing the class
+#### Writing the class
 
 For demo purposes we create a class called `CustomShape` which shall
 display an outer circle and an inner circle, with minimal API. There are
 only 2 subcontrols that will be painted in the skinlet later:
 
-[source]
-....
+```
 class CustomShape : public QskControl
 {
     Q_OBJECT
@@ -178,9 +169,9 @@ public:
     {
     }
 };
-....
+```
 
-==== Writing the skinlet
+#### Writing the skinlet
 
 Writing the skinlet is the hard part of the work. We need the following
 things in our skinlet:
@@ -191,10 +182,10 @@ from the control, so since in our case we have a subcontrol `Panel` and
 `InnerShapeRole`. The node roles are often set in the constructor of the
 class.
 
-IMPORTANT: The constructor of the skinlet needs to be invokable!
+**❗ IMPORTANT**\
+The constructor of the skinlet needs to be invokable!
 
-[source]
-....
+```
 class CustomShapeSkinlet : public QskSkinlet
 {
     Q_GADGET
@@ -209,7 +200,7 @@ public:
     {
         setNodeRoles( { PanelRole, InnerShapeRole } );
     }
-....
+```
 
 * The enclosing rectangle for each subcontrol. This can be just the
 `contentsRect`, but we can define it more accurately if we want by
@@ -217,8 +208,7 @@ applying some metrics. If the code below is hard to understand, the
 important thing to take away from it is that different subcontrols can
 have different enclosing rectangles.
 
-[source]
-....
+```
     QRectF subControlRect( const QskSkinnable* skinnable, const QRectF& contentsRect, QskAspect::Subcontrol subControl ) const override
     {
         const auto* customShape = static_cast< const CustomShape* >( skinnable );
@@ -234,7 +224,7 @@ have different enclosing rectangles.
         }
 
         return QskSkinlet::subControlRect( skinnable, contentsRect, subControl );
-....
+```
 
 * The code to actually draw the nodes. In our case of an outer circle
 and an inner circle, the code for each subcontrol / node role is quite
@@ -243,8 +233,7 @@ similar. The method `updateSubNode()`, which is reimplemented from
 might not be straight forward to understand, the gist of it is that for
 each node role we draw a circle by creating a `BoxNode`.
 
-[source]
-....
+```
 protected:
     QSGNode* updateSubNode( const QskSkinnable* skinnable, quint8 nodeRole, QSGNode* node ) const override
     {
@@ -279,16 +268,15 @@ protected:
         return QskSkinlet::updateSubNode( skinnable, nodeRole, node );
     }
 };
-....
+```
 
-==== Connecting class and skinlet
+#### Connecting class and skinlet
 
 In our skin, we need to declare that the skinlet above will be
 responsible of drawing our control via `declareSkinlet`. Also, we can
 style our control with skin hints:
 
-[source]
-....
+```
 class MySkin : public QskSkin
 {
 
@@ -302,7 +290,7 @@ public:
        setGradient( CustomShape::InnerShape, Qt::magenta );
     }
 };
-....
+```
 
 SkinFactories etc. are again omitted here. Finally we can draw our
 control; the effort might seem excessive, but we wrote the control with
@@ -310,5 +298,6 @@ all capabilities of styling; in addition, the control will react to size
 changes properly. A simpler version with hardcoded values for margins,
 colors etc. can be written with less code.
 
-.A class with an own skinlet
-image::/doc/tutorials/images/control-with-skinlet.png[Control with skinlet]
+**A class with an own skinlet**
+
+![Control with skinlet](/doc/tutorials/images/control-with-skinlet.png)
diff --git a/doc/tutorials/10-scene-graph.asciidoc b/doc/tutorials/10-scene-graph.md
similarity index 78%
rename from doc/tutorials/10-scene-graph.asciidoc
rename to doc/tutorials/10-scene-graph.md
index 75f6b7d3..741b47e3 100644
--- a/doc/tutorials/10-scene-graph.asciidoc
+++ b/doc/tutorials/10-scene-graph.md
@@ -1,12 +1,6 @@
----
-title: 9. Scene graph representations of controls
-layout: docs
----
+# Tutorials {#tutorials}
 
-:doctitle: 9. Scene graph representations of controls
-:notitle:
-
-== QSkinny - Scene graph representations of controls
+## Scene graph representations of controls
 
 Each control that is displayed on the screen consists of one or more
 scene graph nodes. Those nodes can be either basic shapes like
@@ -15,19 +9,19 @@ with transform nodes), opacity or clipping.
 
 The source code below shows a minimal example displaying a button:
 
-[source]
-....
+```
 auto* button = new QskPushButton( "button" );
 
 QskWindow window;
 window.addItem( button );
 window.show();
-....
+```
 
 For this example, the scene graph will contain the following nodes:
 
-.Scene graph representation of a button
-image::/doc/tutorials/images/skins-sg-1.png[Scene graph nodes for a button]
+**Scene graph representation of a button**
+
+![Scene graph nodes for a button](/doc/tutorials/images/skins-sg-1.png)
 
 The top two nodes (root and Quick root item) are created for every
 QtQuick application. The button itself consists of 5 nodes in our case:
@@ -38,7 +32,7 @@ another geometry node for displaying the text (`text node`).
 
 For an explanation of the different scene graph node types, see the Qt
 documentation of
-https://doc.qt.io/qt-5/qsgnode.html#NodeType-enum[QSGNode::NodeType].
+[QSGNode::NodeType](https://doc.qt.io/qt-5/qsgnode.html#NodeType-enum).
 
 The example above is the simplest form of a button, in practice there
 might be more nodes per control, for instance an opacity node or a clip
@@ -47,20 +41,20 @@ node.
 Now we add more elements to the UI by putting the button inside a layout
 (`QskBox`):
 
-[source]
-....
+```
 auto* box = new QskBox;
 auto* button = new QskPushButton( "button", box );
 
 QskWindow window;
 window.addItem( box );
 window.show();
-....
+```
 
 Then the scene graph has the following structure:
 
-.Scene graph representation of a button inside a box
-image::/doc/tutorials/images/skins-sg-2.png[Scene graph nodes for a button in a box]
+**Scene graph representation of a button inside a box**
+
+![Scene graph nodes for a button in a box](/doc/tutorials/images/skins-sg-2.png)
 
 Here we can see that since the box is a parent of the button, the `box
 node` is also a parent of the `button node` in the scene graph. Also, the
diff --git a/doc/tutorials/11-How-to-build-for-Wasm.asciidoc b/doc/tutorials/11-How-to-build-for-Wasm.md
similarity index 77%
rename from doc/tutorials/11-How-to-build-for-Wasm.asciidoc
rename to doc/tutorials/11-How-to-build-for-Wasm.md
index d023fd95..d57d0649 100644
--- a/doc/tutorials/11-How-to-build-for-Wasm.asciidoc
+++ b/doc/tutorials/11-How-to-build-for-Wasm.md
@@ -1,53 +1,42 @@
----
-title: 10. Building QSkinny for WebAssembly (Wasm)
-layout: docs
----
+# Tutorials {#tutorials}
 
-:doctitle: 10. Building QSkinny for WebAssembly (Wasm)
-:notitle:
+## Building QSkinny for WebAssembly (Wasm)
 
-== 10. Building QSkinny for WebAssembly (Wasm)
-
-
-=== Build Qt for Wasm
+### Build Qt for Wasm
 
 Build Qt for Wasm from source as described here: https://doc.qt.io/qt-6/wasm.html#building-qt-from-source ; The verified Qt version for QSkinny as of this writing was 6.6.0. It might also work to use a downloaded version of Qt for Wasm, but some additional libraries will need to be built.
 After configuring Qt as described in the link above, for QSkinny you will need the qtbase, qtdeclarative, qtshadertools and qtsvg modules.
 Assuming the Emscripten SDK in `~/dev/emscripten` and Qt in `~/dev/qt6`, Qt can be compiled the following way:
 
-[source]
-....
+```
 cd ~/dev/qt6
 source "~/dev/emsdk/emsdk_env.sh"
 ./configure -platform wasm-emscripten -qt-host-path ~/Qt/6.6.0/gcc_64/ -prefix $PWD/qtbase -submodules qtbase,qtdeclarative,qtshadertools,qtsvg
 cmake --build . -t qtbase -t qtdeclarative -t qtshadertools -t qtsvg
-....
+```
 
 This will install all required libs in `~/dev/qt6/qtbase/lib`.
 
-
-=== Build QSkinny for Wasm
+### Build QSkinny for Wasm
 
 With the Qt version from above QSkinny can be built for WAsm, assuming it has been checked out at `~/dev/qskinny`. Note the configuration option `BUILD_QSKDLL=OFF` for static
  builds:
 
-[source]
-....
+```
 mkdir -p ~/dev/qskinny-wasm-build
 source "~/dev/emsdk/emsdk_env.sh"
 ~/dev/qt6/qtbase/bin/qt-cmake -S ~/dev/qskinny -B ~/dev/qskinny-wasm-build -DBUILD_QSKDLL=OFF
 make
-....
+```
 
-
-=== Run QSkinny for Wasm
+### Run QSkinny for Wasm
 
 Qt creates the HTML wrappers automatically, so there is not much to do except letting Emscripten start the server and open our app in the browser:
 
-[source]
-....
+```
 /usr/bin/python3 ~/dev/emsdk/upstream/emscripten/emrun.py --browser firefox --port 30001 --no_emrun_detect  ~/dev/qskinny-wasm-build/examples/bin/iotdashboard.html
-....
+```
 
-.The IOT dashboard example in a browser
-image::/doc/tutorials/images/iotdashboard-wasm.png[The IOT dashboard example in a browser]
+**The IOT dashboard example in a browser**
+
+![The IOT dashboard example in a browser](/doc/tutorials/images/iotdashboard-wasm.png)
diff --git a/doc/tutorials/index.md b/doc/tutorials/index.md
deleted file mode 100644
index e98636ee..00000000
--- a/doc/tutorials/index.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-title: Tutorials
-excerpt: In this section you'll find the QSkinny tutorials.
-layout: docs
----
-