Move Qt Core examples under a common subdirectory

Qt Core examples were scattered into several subdirectories under
qtbase/examples. This caused an issue with the example manifest
file generated by QDoc; it expects to find all examples under a
common directory in order to produde correct paths to the example
.pro files. Qt Creator will not find the examples without a valid
manifest file.

This change moves the examples and edits the documentation files
accordingly.

Task-number: QTBUG-41963
Change-Id: I51d86782e0ba21c5c9bae5f15401ec774abe5cf8
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>

doc/global/manifest-meta.qdocconf

@@ -255,7 +255,12 @@ manifestmeta.ios.tags                  = ios
 # add a generic thumbnail image to examples that do not have any images in their documentation
 manifestmeta.thumbnail.attributes  = "imageUrl:qthelp\://org.qt-project.qtdoc.$QT_VERSION_TAG/qtdoc/images/qt-codesample.png"
 
-manifestmeta.thumbnail.names    =      "QtConcurrent/Map Example" \
+manifestmeta.thumbnail.names    =      "QtCore/Contiguous Cache Example" \
+                                       "QtCore/Custom Type Example" \
+                                       "QtCore/JSON Save Game Example" \
+                                       "QtCore/Semaphores Example" \
+                                       "QtCore/Wait Conditions Example" \
+                                       "QtConcurrent/Map Example" \
                                        "QtConcurrent/QtConcurrent Word Count Example" \
                                        "QtConcurrent/Run Function Example" \
                                        "QtGui/Raster Window Example" \

examples/corelib/corelib.pro

@@ -0,0 +1,8 @@
+TEMPLATE = subdirs
+CONFIG += no_docs_target
+
+SUBDIRS = \
+    ipc \
+    json \
+    threads \
+    tools

examples/corelib/ipc/doc/src/localfortuneclient.qdoc

@@ -26,7 +26,7 @@
 ****************************************************************************/
 
 /*!
-    \example localfortuneclient
+    \example ipc/localfortuneclient
     \title Local Fortune Client Example
     \ingroup examples-ipc
     \brief Demonstrates using QLocalSocket for a simple local service client.

examples/corelib/ipc/doc/src/localfortuneserver.qdoc

@@ -26,7 +26,7 @@
 ****************************************************************************/
 
 /*!
-    \example localfortuneserver
+    \example ipc/localfortuneserver
     \title Local Fortune Server Example
     \ingroup examples-ipc
     \brief Demonstrates using QLocalServer and QLocalSocket for serving a simple local service.

examples/corelib/ipc/doc/src/sharedmemory.qdoc

@@ -26,7 +26,7 @@
 ****************************************************************************/
 
 /*!
-  \example sharedmemory
+  \example ipc/sharedmemory
   \title Shared Memory Example
   \ingroup examples-ipc
   \brief Demonstrates doing inter-process communication using shared memory with
@@ -40,7 +40,7 @@
   dialog is displayed and then control is passed to the application in
   the standard way.
 
-  \snippet sharedmemory/main.cpp 0
+  \snippet ipc/sharedmemory/main.cpp 0
 
   Two instances of class Dialog appear.
 
@@ -51,12 +51,12 @@
   loadFromFile() and loadFromMemory() that correspond to the two
   buttons on the dialog.
 
-  \snippet sharedmemory/dialog.h 0
+  \snippet ipc/sharedmemory/dialog.h 0
 
   The constructor builds the user interface widgets and connects the
   clicked() signal of each button to the corresponding slot function.
 
-  \snippet sharedmemory/dialog.cpp 0
+  \snippet ipc/sharedmemory/dialog.cpp 0
 
   Note that "QSharedMemoryExample" is passed to the \l {QSharedMemory}
   {QSharedMemory()} constructor to be used as the key. This will be
@@ -69,7 +69,7 @@
   that segment is detached from the process, so we can be assured of
   starting off the example correctly.
 
-  \snippet sharedmemory/dialog.cpp 1
+  \snippet ipc/sharedmemory/dialog.cpp 1
 
   The user is then asked to select an image file using
   QFileDialog::getOpenFileName(). The selected file is loaded into a
@@ -85,7 +85,7 @@
   to the image data, which we then use to do a memcopy() from the
   QBuffer into the shared memory segment.
 
-  \snippet sharedmemory/dialog.cpp 2
+  \snippet ipc/sharedmemory/dialog.cpp 2
 
   Note that we \l {QSharedMemory::} {lock()} the shared memory segment
   before we copy into it, and we \l {QSharedMemory::} {unlock()} it
@@ -117,7 +117,7 @@
   then streams the data into a QImage and \l {QSharedMemory::unlock()}
   {unlocks} the segment.
 
-  \snippet sharedmemory/dialog.cpp 3
+  \snippet ipc/sharedmemory/dialog.cpp 3
 
   In this case, the function does \l {QSharedMemory::} {detach()} from
   the segment, because now we are effectively finished using

examples/corelib/ipc/localfortuneclient/localfortuneclient.pro

@@ -4,5 +4,5 @@ SOURCES       = client.cpp \
 QT           += network widgets
 
 # install
-target.path = $$[QT_INSTALL_EXAMPLES]/ipc/localfortuneclient
+target.path = $$[QT_INSTALL_EXAMPLES]/corelib/ipc/localfortuneclient
 INSTALLS += target

examples/corelib/ipc/localfortuneserver/localfortuneserver.pro

@@ -4,5 +4,5 @@ SOURCES       = server.cpp \
 QT           += network widgets
 
 # install
-target.path = $$[QT_INSTALL_EXAMPLES]/ipc/localfortuneserver
+target.path = $$[QT_INSTALL_EXAMPLES]/corelib/ipc/localfortuneserver
 INSTALLS += target

examples/corelib/ipc/sharedmemory/sharedmemory.pro

@@ -11,5 +11,5 @@ FORMS += dialog.ui
 EXAMPLE_FILES = *.png
 
 # install
-target.path = $$[QT_INSTALL_EXAMPLES]/ipc/sharedmemory
+target.path = $$[QT_INSTALL_EXAMPLES]/corelib/ipc/sharedmemory
 INSTALLS += target

examples/corelib/json/savegame/doc/src/savegame.qdoc

@@ -26,7 +26,7 @@
 ****************************************************************************/
 
 /*!
-    \example savegame
+    \example json/savegame
     \title JSON Save Game Example
 
     \brief The JSON Save Game example demonstrates how to save and load a
@@ -50,12 +50,12 @@
 
     It provides read() and write() functions to serialise its member variables.
 
-    \snippet savegame/character.h 0
+    \snippet json/savegame/character.h 0
 
     Of particular interest to us are the read and write function
     implementations:
 
-    \snippet savegame/character.cpp 0
+    \snippet json/savegame/character.cpp 0
 
     In the read() function, we assign Character's members values from the
     QJsonObject argument. You can use either \l QJsonObject::operator[]() or
@@ -64,7 +64,7 @@
     could check if the keys are valid before attempting to read them with
     QJsonObject::contains(), but we assume that they are.
 
-    \snippet savegame/character.cpp 1
+    \snippet json/savegame/character.cpp 1
 
     In the write() function, we do the reverse of the read() function; assign
     values from the Character object to the JSON object. As with accessing
@@ -74,13 +74,13 @@
 
     Next up is the Level class:
 
-    \snippet savegame/level.h 0
+    \snippet json/savegame/level.h 0
 
     We want to have several levels in our game, each with several NPCs, so we
     keep a QList of Character objects. We also provide the familiar read() and
     write() functions.
 
-    \snippet savegame/level.cpp 0
+    \snippet json/savegame/level.cpp 0
 
     Containers can be written and read to and from JSON using QJsonArray. In our
     case, we construct a QJsonArray from the value associated with the key
@@ -94,7 +94,7 @@
     element is used as the key to construct the container when reading it back
     in.
 
-    \snippet savegame/level.cpp 1
+    \snippet json/savegame/level.cpp 1
 
     Again, the write() function is similar to the read() function, except
     reversed.
@@ -102,7 +102,7 @@
     Having established the Character and Level classes, we can move on to
     the Game class:
 
-    \snippet savegame/game.h 0
+    \snippet json/savegame/game.h 0
 
     First of all, we define the \c SaveFormat enum. This will allow us to
     specify the format in which the game should be saved: \c Json or \c Binary.
@@ -112,12 +112,12 @@
 
     The read() and write() functions are used by saveGame() and loadGame().
 
-    \snippet savegame/game.cpp 0
+    \snippet json/savegame/game.cpp 0
 
     To setup a new game, we create the player and populate the levels and their
     NPCs.
 
-    \snippet savegame/game.cpp 1
+    \snippet json/savegame/game.cpp 1
 
     The first thing we do in the read() function is tell the player to read
     itself. We then clear the levels list so that calling loadGame() on the same
@@ -125,11 +125,11 @@
 
     We then populate the level list by reading each Level from a QJsonArray.
 
-    \snippet savegame/game.cpp 2
+    \snippet json/savegame/game.cpp 2
 
     We write the game to JSON similarly to how we write Level.
 
-    \snippet savegame/game.cpp 3
+    \snippet json/savegame/game.cpp 3
 
     When loading a saved game in loadGame(), the first thing we do is open the
     save file based on which format it was saved to; \c "save.json" for JSON,
@@ -144,7 +144,7 @@
     After constructing the QJsonDocument, we instruct the Game object to read
     itself and then return \c true to indicate success.
 
-    \snippet savegame/game.cpp 4
+    \snippet json/savegame/game.cpp 4
 
     Not surprisingly, saveGame() looks very much like loadGame(). We determine
     the file extension based on the format, print a warning and return \c false
@@ -155,7 +155,7 @@
 
     We are now ready to enter main():
 
-    \snippet savegame/main.cpp 0
+    \snippet json/savegame/main.cpp 0
 
     Since we're only interested in demonstrating \e serialization of a game with
     JSON, our game is not actually playable. Therefore, we only need
@@ -163,7 +163,7 @@
     the player had a great time and made lots of progress, altering the internal
     state of our Character, Level and Game objects.
 
-    \snippet savegame/main.cpp 1
+    \snippet json/savegame/main.cpp 1
 
     When the player has finished, we save their game. For demonstration
     purposes, we serialize to both JSON and binary. You can examine the contents

examples/corelib/json/savegame/savegame.pro

@@ -8,7 +8,7 @@ CONFIG -= app_bundle
 TEMPLATE = app
 
 # install
-target.path = $$[QT_INSTALL_EXAMPLES]/json/savegame
+target.path = $$[QT_INSTALL_EXAMPLES]/corelib/json/savegame
 INSTALLS += target
 
 SOURCES += main.cpp \

examples/corelib/threads/doc/src/mandelbrot.qdoc

@@ -26,7 +26,7 @@
 ****************************************************************************/
 
 /*!
-    \example mandelbrot
+    \example threads/mandelbrot
     \title Mandelbrot Example
     \ingroup qtconcurrent-mtexamples
 
@@ -101,7 +101,7 @@
 
     We'll start with the definition of the \c RenderThread class:
 
-    \snippet mandelbrot/renderthread.h 0
+    \snippet threads/mandelbrot/renderthread.h 0
 
     The class inherits QThread so that it gains the ability to run in
     a separate thread. Apart from the constructor and destructor, \c
@@ -117,7 +117,7 @@
 
     \section1 RenderThread Class Implementation
 
-    \snippet mandelbrot/renderthread.cpp 0
+    \snippet threads/mandelbrot/renderthread.cpp 0
 
     In the constructor, we initialize the \c restart and \c abort
     variables to \c false. These variables control the flow of the \c
@@ -126,7 +126,7 @@
     We also initialize the \c colormap array, which contains a series
     of RGB colors.
 
-    \snippet mandelbrot/renderthread.cpp 1
+    \snippet threads/mandelbrot/renderthread.cpp 1
 
     The destructor can be called at any point while the thread is
     active. We set \c abort to \c true to tell \c run() to stop
@@ -147,7 +147,7 @@
     until \c run() has exited before the base class destructor is
     invoked.
 
-    \snippet mandelbrot/renderthread.cpp 2
+    \snippet threads/mandelbrot/renderthread.cpp 2
 
     The \c render() function is called by the \c MandelbrotWidget
     whenever it needs to generate a new image of the Mandelbrot set.
@@ -161,7 +161,7 @@
     computation and start again with the new parameters) and wakes up
     the thread, which might be sleeping.
 
-    \snippet mandelbrot/renderthread.cpp 3
+    \snippet threads/mandelbrot/renderthread.cpp 3
 
     \c run() is quite a big function, so we'll break it down into
     parts.
@@ -177,10 +177,10 @@
 
     The \c forever keyword is, like \c foreach, a Qt pseudo-keyword.
 
-    \snippet mandelbrot/renderthread.cpp 4
+    \snippet threads/mandelbrot/renderthread.cpp 4
-    \snippet mandelbrot/renderthread.cpp 5
+    \snippet threads/mandelbrot/renderthread.cpp 5
-    \snippet mandelbrot/renderthread.cpp 6
+    \snippet threads/mandelbrot/renderthread.cpp 6
-    \snippet mandelbrot/renderthread.cpp 7
+    \snippet threads/mandelbrot/renderthread.cpp 7
 
     Then comes the core of the algorithm. Instead of trying to create
     a perfect Mandelbrot set image, we do multiple passes and
@@ -197,15 +197,15 @@
 
     The core algorithm is beyond the scope of this tutorial.
 
-    \snippet mandelbrot/renderthread.cpp 8
+    \snippet threads/mandelbrot/renderthread.cpp 8
-    \snippet mandelbrot/renderthread.cpp 9
+    \snippet threads/mandelbrot/renderthread.cpp 9
 
     Once we're done with all the iterations, we call
     QWaitCondition::wait() to put the thread to sleep by calling,
     unless \c restart is \c true. There's no use in keeping a worker
     thread looping indefinitely while there's nothing to do.
 
-    \snippet mandelbrot/renderthread.cpp 10
+    \snippet threads/mandelbrot/renderthread.cpp 10
 
     The \c rgbFromWaveLength() function is a helper function that
     converts a wave length to a RGB value compatible with 32-bit
@@ -217,7 +217,7 @@
     The \c MandelbrotWidget class uses \c RenderThread to draw the
     Mandelbrot set on screen. Here's the class definition:
 
-    \snippet mandelbrot/mandelbrotwidget.h 0
+    \snippet threads/mandelbrot/mandelbrotwidget.h 0
 
     The widget reimplements many event handlers from QWidget. In
     addition, it has an \c updatePixmap() slot that we'll connect to
@@ -230,12 +230,12 @@
 
     \section1 MandelbrotWidget Class Implementation
 
-    \snippet mandelbrot/mandelbrotwidget.cpp 0
+    \snippet threads/mandelbrot/mandelbrotwidget.cpp 0
 
     The implementation starts with a few contants that we'll need
     later on.
 
-    \snippet mandelbrot/mandelbrotwidget.cpp 1
+    \snippet threads/mandelbrot/mandelbrotwidget.cpp 1
 
     The interesting part of the constructor is the
     qRegisterMetaType() and QObject::connect() calls. Let's start
@@ -258,19 +258,19 @@
     template function qRegisterMetaType() before we can use QImage
     as parameter in queued connections.
 
-    \snippet mandelbrot/mandelbrotwidget.cpp 2
+    \snippet threads/mandelbrot/mandelbrotwidget.cpp 2
-    \snippet mandelbrot/mandelbrotwidget.cpp 3
+    \snippet threads/mandelbrot/mandelbrotwidget.cpp 3
-    \snippet mandelbrot/mandelbrotwidget.cpp 4
+    \snippet threads/mandelbrot/mandelbrotwidget.cpp 4
 
     In \l{QWidget::paintEvent()}{paintEvent()}, we start by filling
     the background with black. If we have nothing yet to paint (\c
     pixmap is null), we print a message on the widget asking the user
     to be patient and return from the function immediately.
 
-    \snippet mandelbrot/mandelbrotwidget.cpp 5
+    \snippet threads/mandelbrot/mandelbrotwidget.cpp 5
-    \snippet mandelbrot/mandelbrotwidget.cpp 6
+    \snippet threads/mandelbrot/mandelbrotwidget.cpp 6
-    \snippet mandelbrot/mandelbrotwidget.cpp 7
+    \snippet threads/mandelbrot/mandelbrotwidget.cpp 7
-    \snippet mandelbrot/mandelbrotwidget.cpp 8
+    \snippet threads/mandelbrot/mandelbrotwidget.cpp 8
 
     If the pixmap has the right scale factor, we draw the pixmap directly onto
     the widget. Otherwise, we scale and translate the \l{Coordinate
@@ -280,12 +280,12 @@
     QPainter::save() and QPainter::restore() make sure that any painting
     performed afterwards uses the standard coordinate system.
 
-    \snippet mandelbrot/mandelbrotwidget.cpp 9
+    \snippet threads/mandelbrot/mandelbrotwidget.cpp 9
 
     At the end of the paint event handler, we draw a text string and
     a semi-transparent rectangle on top of the fractal.
 
-    \snippet mandelbrot/mandelbrotwidget.cpp 10
+    \snippet threads/mandelbrot/mandelbrotwidget.cpp 10
 
     Whenever the user resizes the widget, we call \c render() to
     start generating a new image, with the same \c centerX, \c
@@ -295,13 +295,13 @@
     called by Qt when the widget is shown the first time to generate
     the image the very first time.
 
-    \snippet mandelbrot/mandelbrotwidget.cpp 11
+    \snippet threads/mandelbrot/mandelbrotwidget.cpp 11
 
     The key press event handler provides a few keyboard bindings for
     the benefit of users who don't have a mouse. The \c zoom() and \c
     scroll() functions will be covered later.
 
-    \snippet mandelbrot/mandelbrotwidget.cpp 12
+    \snippet threads/mandelbrot/mandelbrotwidget.cpp 12
 
     The wheel event handler is reimplemented to make the mouse wheel
     control the zoom level. QWheelEvent::delta() returns the angle of
@@ -312,18 +312,18 @@
     (i.e., +30 degrees), the zoom factor becomes \c ZoomInFactor
     to the second power, i.e. 0.8 * 0.8 = 0.64.
 
-    \snippet mandelbrot/mandelbrotwidget.cpp 13
+    \snippet threads/mandelbrot/mandelbrotwidget.cpp 13
 
     When the user presses the left mouse button, we store the mouse
     pointer position in \c lastDragPos.
 
-    \snippet mandelbrot/mandelbrotwidget.cpp 14
+    \snippet threads/mandelbrot/mandelbrotwidget.cpp 14
 
     When the user moves the mouse pointer while the left mouse button
     is pressed, we adjust \c pixmapOffset to paint the pixmap at a
     shifted position and call QWidget::update() to force a repaint.
 
-    \snippet mandelbrot/mandelbrotwidget.cpp 15
+    \snippet threads/mandelbrot/mandelbrotwidget.cpp 15
 
     When the left mouse button is released, we update \c pixmapOffset
     just like we did on a mouse move and we reset \c lastDragPos to a
@@ -332,7 +332,7 @@
     because areas revealed when dragging the pixmap are drawn in
     black.)
 
-    \snippet mandelbrot/mandelbrotwidget.cpp 16
+    \snippet threads/mandelbrot/mandelbrotwidget.cpp 16
 
     The \c updatePixmap() slot is invoked when the worker thread has
     finished rendering an image. We start by checking whether a drag
@@ -349,14 +349,14 @@
     be converted into a pixmap. It's better to do the conversion once
     and for all here, rather than in \c paintEvent().
 
-    \snippet mandelbrot/mandelbrotwidget.cpp 17
+    \snippet threads/mandelbrot/mandelbrotwidget.cpp 17
 
     In \c zoom(), we recompute \c curScale. Then we call
     QWidget::update() to draw a scaled pixmap, and we ask the worker
     thread to render a new image corresponding to the new \c curScale
     value.
 
-    \snippet mandelbrot/mandelbrotwidget.cpp 18
+    \snippet threads/mandelbrot/mandelbrotwidget.cpp 18
 
     \c scroll() is similar to \c zoom(), except that the affected
     parameters are \c centerX and \c centerY.
@@ -366,5 +366,5 @@
     The application's multithreaded nature has no impact on its \c
     main() function, which is as simple as usual:
 
-    \snippet mandelbrot/main.cpp 0
+    \snippet threads/mandelbrot/main.cpp 0
 */

examples/corelib/threads/doc/src/queuedcustomtype.qdoc

@@ -26,7 +26,7 @@
 ****************************************************************************/
 
 /*!
-    \example queuedcustomtype
+    \example threads/queuedcustomtype
     \title Queued Custom Type Example
     \brief Demonstrates multi-thread programming using Qt
     \ingroup qtconcurrent-mtexamples
@@ -57,7 +57,7 @@
     constructor and destructor in the public section of the class that the
     meta-object system requires. It describes a colored rectangle.
 
-    \snippet queuedcustomtype/block.h custom type definition and meta-type declaration
+    \snippet threads/queuedcustomtype/block.h custom type definition and meta-type declaration
 
     We will still need to register it with the meta-object system at
     run-time by calling the qRegisterMetaType() template function before
@@ -74,7 +74,7 @@
     \c Block object. The rest of the class is concerned with managing the
     user interface and handling images.
 
-    \snippet queuedcustomtype/window.h Window class definition
+    \snippet threads/queuedcustomtype/window.h Window class definition
 
     The \c Window class also contains a worker thread, provided by a
     \c RenderThread object. This will emit signals to send \c Block objects
@@ -87,22 +87,22 @@
     interface containing a label and two push buttons that are connected to
     slots in the same class.
 
-    \snippet queuedcustomtype/window.cpp Window constructor start
+    \snippet threads/queuedcustomtype/window.cpp Window constructor start
-    \snippet queuedcustomtype/window.cpp set up widgets and connections
+    \snippet threads/queuedcustomtype/window.cpp set up widgets and connections
-    \snippet queuedcustomtype/window.cpp connecting signal with custom type
+    \snippet threads/queuedcustomtype/window.cpp connecting signal with custom type
 
     In the last of these connections, we connect a signal in the
     \c RenderThread object to the \c addBlock(Block) slot in the window.
 
     \dots
-    \snippet queuedcustomtype/window.cpp Window constructor finish
+    \snippet threads/queuedcustomtype/window.cpp Window constructor finish
 
     The rest of the constructor simply sets up the layout of the window.
 
     The \c addBlock(Block) slot receives blocks from the rendering thread via
     the signal-slot connection set up in the constructor:
 
-    \snippet queuedcustomtype/window.cpp Adding blocks to the display
+    \snippet threads/queuedcustomtype/window.cpp Adding blocks to the display
 
     We simply paint these onto the label as they arrive.
 
@@ -112,7 +112,7 @@
     and using the \c sendBlock(Block) signal to send them to other components
     in the example.
 
-    \snippet queuedcustomtype/renderthread.h RenderThread class definition
+    \snippet threads/queuedcustomtype/renderthread.h RenderThread class definition
 
     The constructor and destructor are not quoted here. These take care of
     setting up the thread's internal state and cleaning up when it is destroyed.
@@ -120,13 +120,13 @@
     Processing is started with the \c processImage() function, which calls the
     \c RenderThread class's reimplementation of the QThread::run() function:
 
-    \snippet queuedcustomtype/renderthread.cpp processing the image (start)
+    \snippet threads/queuedcustomtype/renderthread.cpp processing the image (start)
 
     Ignoring the details of the way the image is processed, we see that the
     signal containing a block is emitted in the usual way:
 
     \dots
-    \snippet queuedcustomtype/renderthread.cpp processing the image (finish)
+    \snippet threads/queuedcustomtype/renderthread.cpp processing the image (finish)
 
     Each signal that is emitted will be queued and delivered later to the
     window's \c addBlock(Block) slot.
@@ -137,7 +137,7 @@
     \c Block class as a custom type with the meta-object system by calling the
     qRegisterMetaType() template function:
 
-    \snippet queuedcustomtype/main.cpp main function
+    \snippet threads/queuedcustomtype/main.cpp main function
 
     This call is placed here to ensure that the type is registered before any
     signal-slot connections are made that use it.

examples/corelib/threads/doc/src/semaphores.qdoc

@@ -26,7 +26,7 @@
 ****************************************************************************/
 
 /*!
-    \example semaphores
+    \example threads/semaphores
     \title Semaphores Example
     \brief Demonstrates multi-thread programming using Qt
     \ingroup qtconcurrent-mtexamples
@@ -61,7 +61,7 @@
     Let's start by reviewing the circular buffer and the associated
     semaphores:
 
-    \snippet semaphores/semaphores.cpp 0
+    \snippet threads/semaphores/semaphores.cpp 0
 
     \c DataSize is the amout of data that the producer will generate.
     To keep the example as simple as possible, we make it a constant.
@@ -89,8 +89,8 @@
 
     Let's review the code for the \c Producer class:
 
-    \snippet semaphores/semaphores.cpp 1
+    \snippet threads/semaphores/semaphores.cpp 1
-    \snippet semaphores/semaphores.cpp 2
+    \snippet threads/semaphores/semaphores.cpp 2
 
     The producer generates \c DataSize bytes of data. Before it
     writes a byte to the circular buffer, it must acquire a "free"
@@ -106,8 +106,8 @@
 
     Let's now turn to the \c Consumer class:
 
-    \snippet semaphores/semaphores.cpp 3
+    \snippet threads/semaphores/semaphores.cpp 3
-    \snippet semaphores/semaphores.cpp 4
+    \snippet threads/semaphores/semaphores.cpp 4
 
     The code is very similar to the producer, except that this time
     we acquire a "used" byte and release a "free" byte, instead of
@@ -118,8 +118,8 @@
     In \c main(), we create the two threads and call QThread::wait()
     to ensure that both threads get time to finish before we exit:
 
-    \snippet semaphores/semaphores.cpp 5
+    \snippet threads/semaphores/semaphores.cpp 5
-    \snippet semaphores/semaphores.cpp 6
+    \snippet threads/semaphores/semaphores.cpp 6
 
     So what happens when we run the program? Initially, the producer
     thread is the only one that can do anything; the consumer is

examples/corelib/threads/doc/src/waitconditions.qdoc

@@ -26,7 +26,7 @@
 ****************************************************************************/
 
 /*!
-    \example waitconditions
+    \example threads/waitconditions
     \title Wait Conditions Example
     \brief Demonstrates multi-thread programming using Qt
     \ingroup qtconcurrent-mtexamples
@@ -61,7 +61,7 @@
     Let's start by reviewing the circular buffer and the associated
     synchronization tools:
 
-    \snippet waitconditions/waitconditions.cpp 0
+    \snippet threads/waitconditions/waitconditions.cpp 0
 
     \c DataSize is the amount of data that the producer will generate.
     To keep the example as simple as possible, we make it a constant.
@@ -86,8 +86,8 @@
 
     Let's review the code for the \c Producer class:
 
-    \snippet waitconditions/waitconditions.cpp 1
+    \snippet threads/waitconditions/waitconditions.cpp 1
-    \snippet waitconditions/waitconditions.cpp 2
+    \snippet threads/waitconditions/waitconditions.cpp 2
 
     The producer generates \c DataSize bytes of data. Before it
     writes a byte to the circular buffer, it must first check whether
@@ -110,8 +110,8 @@
 
     Let's turn to the \c Consumer class:
 
-    \snippet waitconditions/waitconditions.cpp 3
+    \snippet threads/waitconditions/waitconditions.cpp 3
-    \snippet waitconditions/waitconditions.cpp 4
+    \snippet threads/waitconditions/waitconditions.cpp 4
 
     The code is very similar to the producer. Before we read the
     byte, we check whether the buffer is empty (\c numUsedBytes is 0)
@@ -126,8 +126,8 @@
     In \c main(), we create the two threads and call QThread::wait()
     to ensure that both threads get time to finish before we exit:
 
-    \snippet waitconditions/waitconditions.cpp 5
+    \snippet threads/waitconditions/waitconditions.cpp 5
-    \snippet waitconditions/waitconditions.cpp 6
+    \snippet threads/waitconditions/waitconditions.cpp 6
 
     So what happens when we run the program? Initially, the producer
     thread is the only one that can do anything; the consumer is

examples/corelib/threads/mandelbrot/mandelbrot.pro

@@ -9,5 +9,5 @@ SOURCES       = main.cpp \
 unix:!mac:!vxworks:!integrity:LIBS += -lm
 
 # install
-target.path = $$[QT_INSTALL_EXAMPLES]/threads/mandelbrot
+target.path = $$[QT_INSTALL_EXAMPLES]/corelib/threads/mandelbrot
 INSTALLS += target

examples/corelib/threads/queuedcustomtype/queuedcustomtype.pro

@@ -8,7 +8,7 @@ SOURCES   = main.cpp \
 QT += widgets
 
 # install
-target.path = $$[QT_INSTALL_EXAMPLES]/threads/mandelbrot
+target.path = $$[QT_INSTALL_EXAMPLES]/corelib/threads/mandelbrot
 INSTALLS += target
 
 

examples/corelib/threads/semaphores/semaphores.pro

@@ -5,5 +5,5 @@ CONFIG -= app_bundle
 CONFIG += console
 
 # install
-target.path = $$[QT_INSTALL_EXAMPLES]/threads/semaphores
+target.path = $$[QT_INSTALL_EXAMPLES]/corelib/threads/semaphores
 INSTALLS += target

examples/corelib/threads/waitconditions/waitconditions.pro

@@ -5,5 +5,5 @@ CONFIG += console
 SOURCES += waitconditions.cpp
 
 # install
-target.path = $$[QT_INSTALL_EXAMPLES]/threads/waitconditions
+target.path = $$[QT_INSTALL_EXAMPLES]/corelib/threads/waitconditions
 INSTALLS += target

examples/corelib/tools/contiguouscache/contiguouscache.pro

@@ -5,5 +5,5 @@ SOURCES       = randomlistmodel.cpp \
                 main.cpp
 
 # install
-target.path = $$[QT_INSTALL_EXAMPLES]/tools/contiguouscache
+target.path = $$[QT_INSTALL_EXAMPLES]/corelib/tools/contiguouscache
 INSTALLS += target

examples/corelib/tools/customtype/customtype.pro

@@ -4,5 +4,5 @@ SOURCES   = main.cpp \
 QT += widgets
 
 # install
-target.path = $$[QT_INSTALL_EXAMPLES]/tools/customcompleter
+target.path = $$[QT_INSTALL_EXAMPLES]/corelib/tools/customcompleter
 INSTALLS += target

examples/corelib/tools/customtypesending/customtypesending.pro

@@ -6,5 +6,5 @@ SOURCES   = main.cpp \
 QT += widgets
 
 # install
-target.path = $$[QT_INSTALL_EXAMPLES]/tools/customcompleter
+target.path = $$[QT_INSTALL_EXAMPLES]/corelib/tools/customcompleter
 INSTALLS += target

examples/corelib/tools/doc/src/contiguouscache.qdoc

@@ -26,7 +26,7 @@
 ****************************************************************************/
 
 /*!
-    \example contiguouscache
+    \example tools/contiguouscache
     \title Contiguous Cache Example
 
     \brief The Contiguous Cache example shows how to use QContiguousCache to manage memory usage for
@@ -40,7 +40,7 @@
     a view requests an item at row N it is also likely to ask for items at rows near
     to N.
 
-    \snippet contiguouscache/randomlistmodel.cpp 0
+    \snippet tools/contiguouscache/randomlistmodel.cpp 0
 
     After getting the row, the class determines if the row is in the bounds
     of the contiguous cache's current range.  It would have been equally valid to
@@ -74,7 +74,7 @@
     to see how the cache range is kept for a local number of rows when running the
     example.
 
-    \snippet contiguouscache/randomlistmodel.cpp 1
+    \snippet tools/contiguouscache/randomlistmodel.cpp 1
 
     It is also worth considering pre-fetching items into the cache outside of the
     application's paint routine.  This can be done either with a separate thread

examples/corelib/tools/doc/src/customtype.qdoc

@@ -26,7 +26,7 @@
 ****************************************************************************/
 
 /*!
-    \example customtype
+    \example tools/customtype
     \title Custom Type Example
 
     \brief The Custom Type example shows how to integrate a custom type into Qt's
@@ -56,7 +56,7 @@
     of information (a QString and a QStringList), each of which can be read
     using trivial getter functions:
 
-    \snippet customtype/message.h custom type definition
+    \snippet tools/customtype/message.h custom type definition
 
     The default constructor, copy constructor and destructor are
     all required, and must be public, if the type is to be integrated into the
@@ -67,14 +67,14 @@
     To enable the type to be used with QVariant, we declare it using the
     Q_DECLARE_METATYPE() macro:
 
-    \snippet customtype/message.h custom type meta-type declaration
+    \snippet tools/customtype/message.h custom type meta-type declaration
 
     We do not need to write any additional code to accompany this macro.
 
     To allow us to see a readable description of each \c Message object when it
     is sent to the debug output stream, we define a streaming operator:
 
-    \snippet customtype/message.h custom type streaming operator
+    \snippet tools/customtype/message.h custom type streaming operator
 
     This facility is useful if you need to insert tracing statements in your
     code for debugging purposes.
@@ -84,11 +84,11 @@
     The implementation of the default constructor, copy constructor and destructor
     are straightforward for the \c Message class:
 
-    \snippet customtype/message.cpp Message class implementation
+    \snippet tools/customtype/message.cpp Message class implementation
 
     The streaming operator is implemented in the following way:
 
-    \snippet customtype/message.cpp custom type streaming operator
+    \snippet tools/customtype/message.cpp custom type streaming operator
 
     Here, we want to represent each value depending on how many lines are stored
     in the message body. We stream text to the QDebug object passed to the
@@ -99,7 +99,7 @@
 
     We include the code for the getter functions for completeness:
 
-    \snippet customtype/message.cpp getter functions
+    \snippet tools/customtype/message.cpp getter functions
 
     With the type fully defined, implemented, and integrated with the
     meta-object system, we can now use it.
@@ -109,13 +109,13 @@
     In the example's \c{main()} function, we show how a \c Message object can
     be printed to the console by sending it to the debug stream:
 
-    \snippet customtype/main.cpp printing a custom type
+    \snippet tools/customtype/main.cpp printing a custom type
 
     You can use the type with QVariant in exactly the same way as you would
     use standard Qt value types. Here's how to store a value using the
     QVariant::setValue() function:
 
-    \snippet customtype/main.cpp storing a custom value
+    \snippet tools/customtype/main.cpp storing a custom value
 
     Alternatively, the QVariant::fromValue() and qVariantSetValue() functions
     can be used if you are using a compiler without support for member template
@@ -124,7 +124,7 @@
     The value can be retrieved using the QVariant::value() member template
     function:
 
-    \snippet customtype/main.cpp retrieving a custom value
+    \snippet tools/customtype/main.cpp retrieving a custom value
 
     Alternatively, the qVariantValue() template function can be used if
     you are using a compiler without support for member template functions.

examples/examples.pro

@@ -2,18 +2,15 @@ TEMPLATE      = subdirs
 CONFIG += no_docs_target
 
 SUBDIRS = \
+    corelib \
     dbus \
     embedded \
     gui \
-    ipc \
-    json \
     network \
     qpa \
     qtconcurrent \
     qtestlib \
     sql \
-    threads \
-    tools \
     touch \
     widgets \
     xml

src/corelib/doc/qtcore.qdocconf

@@ -4,7 +4,7 @@ project                 = QtCore
 description             = Qt Core Reference Documentation
 version                 = $QT_VERSION
 
-examplesinstallpath     = core
+examplesinstallpath     = corelib
 
 qhp.projects            = QtCore
 
@@ -35,10 +35,7 @@ sourcedirs  += ..
 exampledirs += \
                ../ \
                snippets \
-               ../../../examples/threads/ \
+               ../../../examples/corelib \
-               ../../../examples/tools/ \
-               ../../../examples/ipc/ \
-               ../../../examples/json/ \
                ../../../examples/network/dnslookup
 
 imagedirs   += images

src/corelib/doc/src/custom-types.qdoc

@@ -61,7 +61,7 @@
 
     The following \c Message class definition includes these members:
 
-    \snippet customtype/message.h custom type definition
+    \snippet tools/customtype/message.h custom type definition
 
     The class also provides a constructor for normal use and two public member functions
     that are used to obtain the private data.
@@ -77,7 +77,7 @@
     to this class, we invoke the Q_DECLARE_METATYPE() macro on the class in the header
     file where it is defined:
 
-    \snippet customtype/message.h custom type meta-type declaration
+    \snippet tools/customtype/message.h custom type meta-type declaration
 
     This now makes it possible for \c Message values to be stored in QVariant objects
     and retrieved later. See the \l{Custom Type Example} for code that demonstrates
@@ -104,19 +104,19 @@
     The \l{Queued Custom Type Example} declares a \c Block class which is registered
     in the \c{main.cpp} file:
 
-    \snippet queuedcustomtype/main.cpp main start
+    \snippet threads/queuedcustomtype/main.cpp main start
     \dots
-    \snippet queuedcustomtype/main.cpp register meta-type for queued communications
+    \snippet threads/queuedcustomtype/main.cpp register meta-type for queued communications
     \dots
-    \snippet queuedcustomtype/main.cpp main finish
+    \snippet threads/queuedcustomtype/main.cpp main finish
 
     This type is later used in a signal-slot connection in the \c{window.cpp} file:
 
-    \snippet queuedcustomtype/window.cpp Window constructor start
+    \snippet threads/queuedcustomtype/window.cpp Window constructor start
     \dots
-    \snippet queuedcustomtype/window.cpp connecting signal with custom type
+    \snippet threads/queuedcustomtype/window.cpp connecting signal with custom type
     \dots
-    \snippet queuedcustomtype/window.cpp Window constructor finish
+    \snippet threads/queuedcustomtype/window.cpp Window constructor finish
 
     If a type is used in a queued connection without being registered, a warning will be
     printed at the console; for example:
@@ -131,18 +131,18 @@
     It is often quite useful to make a custom type printable for debugging purposes,
     as in the following code:
 
-    \snippet customtype/main.cpp printing a custom type
+    \snippet tools/customtype/main.cpp printing a custom type
 
     This is achieved by creating a streaming operator for the type, which is often
     defined in the header file for that type:
 
-    \snippet customtype/message.h custom type streaming operator
+    \snippet tools/customtype/message.h custom type streaming operator
 
     The implementation for the \c Message type in the \l{Custom Type Example}
     goes to some effort to make the printable representation as readable as
     possible:
 
-    \snippet customtype/message.cpp custom type streaming operator
+    \snippet tools/customtype/message.cpp custom type streaming operator
 
     The output sent to the debug stream can, of course, be made as simple or as
     complicated as you like. Note that the value returned by this function is