Move examples to proper location.
Change-Id: Ib808f5d99cb8217f8786411b531fa5bc7fa5250a Reviewed-by: Martin Smith <martin.smith@digia.com>
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
Before Width: | Height: | Size: 10 KiB After Width: | Height: | Size: 10 KiB |
@ -45,14 +45,14 @@
|
||||
\e{countries.txt} and \e{words.txt}. The resource file contains the
|
||||
following code:
|
||||
|
||||
\quotefile examples/tools/completer/completer.qrc
|
||||
\quotefile completer/completer.qrc
|
||||
|
||||
\section1 FileSystemModel Class Definition
|
||||
|
||||
The \c FileSystemModel class is a subclass of QFileSystemModel, which provides a data
|
||||
model for the local filesystem.
|
||||
|
||||
\snippet examples/tools/completer/fsmodel.h 0
|
||||
\snippet completer/fsmodel.h 0
|
||||
|
||||
This class only has a constructor and a \c data() function as it is only
|
||||
created to enable \c data() to return the entire file path for the
|
||||
@ -65,14 +65,14 @@
|
||||
The constructor for the \c FileSystemModel class is used to pass \a parent to
|
||||
QFileSystemModel.
|
||||
|
||||
\snippet examples/tools/completer/fsmodel.cpp 0
|
||||
\snippet completer/fsmodel.cpp 0
|
||||
|
||||
As mentioned earlier, the \c data() function is reimplemented in order to
|
||||
get it to return the entire file parth for the display role. For example,
|
||||
with a QFileSystemModel, you will see "Program Files" in the view. However, with
|
||||
\c FileSystemModel, you will see "C:\\Program Files".
|
||||
|
||||
\snippet examples/tools/completer/fsmodel.cpp 1
|
||||
\snippet completer/fsmodel.cpp 1
|
||||
|
||||
The screenshots below illustrate this difference:
|
||||
|
||||
@ -90,14 +90,14 @@
|
||||
private slots - \c about(), \c changeCase(), \c changeMode(), \c changeModel(),
|
||||
and \c changeMaxVisible().
|
||||
|
||||
\snippet examples/tools/completer/mainwindow.h 0
|
||||
\snippet completer/mainwindow.h 0
|
||||
|
||||
Within the \c MainWindow class, we have two private functions:
|
||||
\c createMenu() and \c modelFromFile(). We also declare the private widgets
|
||||
needed - three QComboBox objects, a QCheckBox, a QCompleter, a QLabel, and
|
||||
a QLineEdit.
|
||||
|
||||
\snippet examples/tools/completer/mainwindow.h 1
|
||||
\snippet completer/mainwindow.h 1
|
||||
|
||||
\section1 MainWindow Class Implementation
|
||||
|
||||
@ -110,7 +110,7 @@
|
||||
the \c modeCombo is set to "Filtered Popup" and the \c caseCombo is set
|
||||
to "Case Insensitive".
|
||||
|
||||
\snippet examples/tools/completer/mainwindow.cpp 0
|
||||
\snippet completer/mainwindow.cpp 0
|
||||
|
||||
The \c maxVisibleSpinBox is created and determines the number of visible
|
||||
item in the completer
|
||||
@ -119,26 +119,26 @@
|
||||
\c{completer}'s \l{QCompleter::setWrapAround()}{setWrapAround()} property
|
||||
is enabled or disabled.
|
||||
|
||||
\snippet examples/tools/completer/mainwindow.cpp 1
|
||||
\snippet completer/mainwindow.cpp 1
|
||||
|
||||
We instantiate \c contentsLabel and set its size policy to
|
||||
\l{QSizePolicy::Fixed}{fixed}. The combo boxes' \l{QComboBox::activated()}
|
||||
{activated()} signals are then connected to their respective slots.
|
||||
|
||||
\snippet examples/tools/completer/mainwindow.cpp 2
|
||||
\snippet completer/mainwindow.cpp 2
|
||||
|
||||
The \c lineEdit is set up and then we arrange all the widgets using a
|
||||
QGridLayout. The \c changeModel() function is called, to initialize the
|
||||
\c completer.
|
||||
|
||||
\snippet examples/tools/completer/mainwindow.cpp 3
|
||||
\snippet completer/mainwindow.cpp 3
|
||||
|
||||
The \c createMenu() function is used to instantiate the QAction objects
|
||||
needed to fill the \c fileMenu and \c helpMenu. The actions'
|
||||
\l{QAction::triggered()}{triggered()} signals are connected to their
|
||||
respective slots.
|
||||
|
||||
\snippet examples/tools/completer/mainwindow.cpp 4
|
||||
\snippet completer/mainwindow.cpp 4
|
||||
|
||||
The \c modelFromFile() function accepts the \a fileName of a file and
|
||||
processes it depending on its contents.
|
||||
@ -147,26 +147,26 @@
|
||||
QFile::ReadOnly mode. If this is unsuccessful, the function returns an
|
||||
empty QStringListModel.
|
||||
|
||||
\snippet examples/tools/completer/mainwindow.cpp 5
|
||||
\snippet completer/mainwindow.cpp 5
|
||||
|
||||
The mouse cursor is then overridden with Qt::WaitCursor before we fill
|
||||
a QStringList object, \c words, with the contents of \c file. Once this
|
||||
is done, we restore the mouse cursor.
|
||||
|
||||
\snippet examples/tools/completer/mainwindow.cpp 6
|
||||
\snippet completer/mainwindow.cpp 6
|
||||
|
||||
As mentioned earlier, the resources file contains two files -
|
||||
\e{countries.txt} and \e{words.txt}. If the \c file read is \e{words.txt},
|
||||
we return a QStringListModel with \c words as its QStringList and
|
||||
\c completer as its parent.
|
||||
|
||||
\snippet examples/tools/completer/mainwindow.cpp 7
|
||||
\snippet completer/mainwindow.cpp 7
|
||||
|
||||
If the \c file read is \e{countries.txt}, then we require a
|
||||
QStandardItemModel with \c words.count() rows, 2 columns, and \c completer
|
||||
as its parent.
|
||||
|
||||
\snippet examples/tools/completer/mainwindow.cpp 8
|
||||
\snippet completer/mainwindow.cpp 8
|
||||
|
||||
A standard line in \e{countries.txt} is:
|
||||
\quotation
|
||||
@ -177,12 +177,12 @@
|
||||
split the country name and its symbol. Once this is done, we return
|
||||
\c m.
|
||||
|
||||
\snippet examples/tools/completer/mainwindow.cpp 9
|
||||
\snippet completer/mainwindow.cpp 9
|
||||
|
||||
The \c changeMode() function sets the \c{completer}'s mode, depending on
|
||||
the value of \c index.
|
||||
|
||||
\snippet examples/tools/completer/mainwindow.cpp 10
|
||||
\snippet completer/mainwindow.cpp 10
|
||||
|
||||
The \c changeModel() function changes the item model used based on the
|
||||
model selected by the user.
|
||||
@ -191,7 +191,7 @@
|
||||
of \c modelCombo. If \c case is 0, we use an unsorted QFileSystemModel, providing
|
||||
us with a file path excluding the drive label.
|
||||
|
||||
\snippet examples/tools/completer/mainwindow.cpp 11
|
||||
\snippet completer/mainwindow.cpp 11
|
||||
|
||||
Note that we create the model with \c completer as the parent as this
|
||||
allows us to replace the model with a new model. The \c completer will
|
||||
@ -201,14 +201,14 @@
|
||||
If \c case is 1, we use the \c DirModel we defined earlier, resulting in
|
||||
full paths for the files.
|
||||
|
||||
\snippet examples/tools/completer/mainwindow.cpp 12
|
||||
\snippet completer/mainwindow.cpp 12
|
||||
|
||||
When \c case is 2, we attempt to complete names of countries. This requires
|
||||
a QTreeView object, \c treeView. The country names are extracted from
|
||||
\e{countries.txt} and set the popup used to display completions to
|
||||
\c treeView.
|
||||
|
||||
\snippet examples/tools/completer/mainwindow.cpp 13
|
||||
\snippet completer/mainwindow.cpp 13
|
||||
|
||||
The screenshot below shows the Completer with the country list model.
|
||||
|
||||
@ -229,21 +229,21 @@
|
||||
to the \c{completer}'s \l{QCompleter::setWrapAround()}{setWrapAround()}
|
||||
slot.
|
||||
|
||||
\snippet examples/tools/completer/mainwindow.cpp 14
|
||||
\snippet completer/mainwindow.cpp 14
|
||||
|
||||
The \c changeMaxVisible() update the maximum number of visible items in
|
||||
the completer.
|
||||
|
||||
\snippet examples/tools/completer/mainwindow.cpp 15
|
||||
\snippet completer/mainwindow.cpp 15
|
||||
|
||||
The \c about() function provides a brief description about the example.
|
||||
|
||||
\snippet examples/tools/completer/mainwindow.cpp 16
|
||||
\snippet completer/mainwindow.cpp 16
|
||||
|
||||
\section1 \c main() Function
|
||||
|
||||
The \c main() function instantiates QApplication and \c MainWindow and
|
||||
invokes the \l{QWidget::show()}{show()} function.
|
||||
|
||||
\snippet examples/tools/completer/main.cpp 0
|
||||
\snippet completer/main.cpp 0
|
||||
*/
|
@ -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 examples/tools/contiguouscache/randomlistmodel.cpp 0
|
||||
\snippet 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 examples/tools/contiguouscache/randomlistmodel.cpp 1
|
||||
\snippet 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
|
@ -26,7 +26,7 @@
|
||||
****************************************************************************/
|
||||
|
||||
/*!
|
||||
\example tools/echoplugin
|
||||
\example echoplugin
|
||||
\title Echo Plugin Example
|
||||
|
||||
This example shows how to create a Qt plugin.
|
||||
@ -64,7 +64,7 @@
|
||||
The \c EchoWindow class lets us test the \c EchoPlugin through a
|
||||
GUI.
|
||||
|
||||
\snippet examples/tools/echoplugin/echowindow/echowindow.h 0
|
||||
\snippet echoplugin/echowindow/echowindow.h 0
|
||||
|
||||
We load the plugin in \c loadPlugin() and cast it to \c
|
||||
EchoInterface. When the user clicks the \c button we take the
|
||||
@ -75,7 +75,7 @@
|
||||
|
||||
We start with a look at the constructor:
|
||||
|
||||
\snippet examples/tools/echoplugin/echowindow/echowindow.cpp 0
|
||||
\snippet echoplugin/echowindow/echowindow.cpp 0
|
||||
|
||||
We create the widgets and set a title for the window. We then load
|
||||
the plugin. \c loadPlugin() returns false if the plugin could not
|
||||
@ -86,7 +86,7 @@
|
||||
|
||||
Here is the implementation of \c sendEcho():
|
||||
|
||||
\snippet examples/tools/echoplugin/echowindow/echowindow.cpp 1
|
||||
\snippet echoplugin/echowindow/echowindow.cpp 1
|
||||
|
||||
This slot is called when the user pushes \c button or presses
|
||||
enter in \c lineEdit. We call \c echo() of the echo interface. In
|
||||
@ -96,14 +96,14 @@
|
||||
|
||||
Here is the implementation of \c createGUI():
|
||||
|
||||
\snippet examples/tools/echoplugin/echowindow/echowindow.cpp 2
|
||||
\snippet echoplugin/echowindow/echowindow.cpp 2
|
||||
|
||||
We create the widgets and lay them out in a grid layout. We
|
||||
connect the label and line edit to our \c sendEcho() slot.
|
||||
|
||||
Here is the \c loadPlugin() function:
|
||||
|
||||
\snippet examples/tools/echoplugin/echowindow/echowindow.cpp 3
|
||||
\snippet echoplugin/echowindow/echowindow.cpp 3
|
||||
|
||||
Access to plugins at run-time is provided by QPluginLoader. You
|
||||
supply it with the filename of the shared library the plugin is
|
||||
@ -126,7 +126,7 @@
|
||||
virtual functions. If non virtual functions were present in the
|
||||
class you would get misleading compile errors in the moc files.
|
||||
|
||||
\snippet examples/tools/echoplugin/echowindow/echointerface.h 0
|
||||
\snippet echoplugin/echowindow/echointerface.h 0
|
||||
|
||||
We declare \c echo(). In our \c EchoPlugin we use this method to
|
||||
return, or echo, \a message.
|
||||
@ -146,18 +146,18 @@
|
||||
If a class implements more than one interface, they are given as
|
||||
a comma separated list.
|
||||
|
||||
\snippet examples/tools/echoplugin/plugin/echoplugin.h 0
|
||||
\snippet echoplugin/plugin/echoplugin.h 0
|
||||
|
||||
|
||||
\section1 EchoPlugin Class Implementation
|
||||
|
||||
Here is the implementation of \c echo():
|
||||
|
||||
\snippet examples/tools/echoplugin/plugin/echoplugin.cpp 0
|
||||
\snippet echoplugin/plugin/echoplugin.cpp 0
|
||||
|
||||
We simply return the functions parameter.
|
||||
|
||||
\snippet examples/tools/echoplugin/plugin/echoplugin.cpp 1
|
||||
\snippet echoplugin/plugin/echoplugin.cpp 1
|
||||
|
||||
We use the Q_EXPORT_PLUGIN2 macro to let Qt know that the \c
|
||||
EchoPlugin class is a plugin. The first parameter is the name of
|
||||
@ -166,7 +166,7 @@
|
||||
|
||||
\section1 The \c main() function
|
||||
|
||||
\snippet examples/tools/echoplugin/echowindow/main.cpp 0
|
||||
\snippet echoplugin/echowindow/main.cpp 0
|
||||
|
||||
We create an \c EchoWindow and display it as a top-level window.
|
||||
|
||||
@ -179,12 +179,12 @@
|
||||
template and simply includes includes to directories in which
|
||||
the echo window and echo plugin lives:
|
||||
|
||||
\snippet examples/tools/echoplugin/echoplugin.pro 0
|
||||
\snippet echoplugin/echoplugin.pro 0
|
||||
|
||||
The profile for the echo window does not need any plugin specific
|
||||
settings. We move on to the plugin profile:
|
||||
|
||||
\snippet examples/tools/echoplugin/plugin/plugin.pro 0
|
||||
\snippet echoplugin/plugin/plugin.pro 0
|
||||
|
||||
We need to set the TEMPLATE as we now want to make a library
|
||||
instead of an executable. We also need to tell qmake that we are
|
Before Width: | Height: | Size: 5.8 KiB After Width: | Height: | Size: 5.8 KiB |
@ -26,7 +26,7 @@
|
||||
****************************************************************************/
|
||||
|
||||
/*!
|
||||
\example tools/i18n
|
||||
\example i18n
|
||||
\title I18N Example
|
||||
|
||||
The Internationalization (I18N) example demonstrates Qt's support for translated
|
Before Width: | Height: | Size: 8.5 KiB After Width: | Height: | Size: 8.5 KiB |
Before Width: | Height: | Size: 7.4 KiB After Width: | Height: | Size: 7.4 KiB |
@ -26,7 +26,7 @@
|
||||
****************************************************************************/
|
||||
|
||||
/*!
|
||||
\example tools/plugandpaint
|
||||
\example plugandpaint
|
||||
\title Plug & Paint Example
|
||||
|
||||
The Plug & Paint example demonstrates how to write Qt
|
||||
@ -47,8 +47,8 @@
|
||||
through plugins, we recommend that you start by reading this
|
||||
overview, which explains how to make an application use plugins.
|
||||
Afterward, you can read the
|
||||
\l{tools/plugandpaintplugins/basictools}{Basic Tools} and
|
||||
\l{tools/plugandpaintplugins/extrafilters}{Extra Filters}
|
||||
\l{plugandpaintplugins/basictools}{Basic Tools} and
|
||||
\l{plugandpaintplugins/extrafilters}{Extra Filters}
|
||||
overviews, which show how to implement static and dynamic
|
||||
plugins, respectively.
|
||||
|
||||
@ -74,7 +74,7 @@
|
||||
in the plugins.
|
||||
|
||||
|
||||
\snippet examples/tools/plugandpaint/interfaces.h 0
|
||||
\snippet plugandpaint/interfaces.h 0
|
||||
|
||||
The \c BrushInterface class declares four pure virtual functions.
|
||||
The first pure virtual function, \c brushes(), returns a list of
|
||||
@ -96,7 +96,7 @@
|
||||
virtual destructor. We provide the destructor to keep these
|
||||
compilers happy.
|
||||
|
||||
\snippet examples/tools/plugandpaint/interfaces.h 1
|
||||
\snippet plugandpaint/interfaces.h 1
|
||||
|
||||
The \c ShapeInterface class declares a \c shapes() function that
|
||||
works the same as \c{BrushInterface}'s \c brushes() function, and
|
||||
@ -106,13 +106,13 @@
|
||||
parent parameter can be used by the plugin to pop up a dialog
|
||||
asking the user to specify more information.
|
||||
|
||||
\snippet examples/tools/plugandpaint/interfaces.h 2
|
||||
\snippet plugandpaint/interfaces.h 2
|
||||
|
||||
The \c FilterInterface class declares a \c filters() function
|
||||
that returns a list of filter names, and a \c filterImage()
|
||||
function that applies a filter to an image.
|
||||
|
||||
\snippet examples/tools/plugandpaint/interfaces.h 4
|
||||
\snippet plugandpaint/interfaces.h 4
|
||||
|
||||
To make it possible to query at run-time whether a plugin
|
||||
implements a given interface, we must use the \c
|
||||
@ -125,8 +125,8 @@
|
||||
a good idea to include a version number in the string, as we did
|
||||
above.
|
||||
|
||||
The \l{tools/plugandpaintplugins/basictools}{Basic Tools} plugin
|
||||
and the \l{tools/plugandpaintplugins/extrafilters}{Extra Filters}
|
||||
The \l{plugandpaintplugins/basictools}{Basic Tools} plugin
|
||||
and the \l{plugandpaintplugins/extrafilters}{Extra Filters}
|
||||
plugin shows how to derive from \c BrushInterface, \c
|
||||
ShapeInterface, and \c FilterInterface.
|
||||
|
||||
@ -144,7 +144,7 @@
|
||||
\l{mainwindows/application}{Application}). Here, we'll
|
||||
concentrate on the parts of the code that are related to plugins.
|
||||
|
||||
\snippet examples/tools/plugandpaint/mainwindow.cpp 4
|
||||
\snippet plugandpaint/mainwindow.cpp 4
|
||||
|
||||
The \c loadPlugins() function is called from the \c MainWindow
|
||||
constructor to detect plugins and update the \uicontrol{Brush},
|
||||
@ -155,7 +155,7 @@
|
||||
QObject. That QObject implements plugin interfaces using multiple
|
||||
inheritance.
|
||||
|
||||
\snippet examples/tools/plugandpaint/mainwindow.cpp 5
|
||||
\snippet plugandpaint/mainwindow.cpp 5
|
||||
|
||||
The next step is to load dynamic plugins. We initialize the \c
|
||||
pluginsDir member variable to refer to the \c plugins
|
||||
@ -166,9 +166,9 @@
|
||||
this file is usually located in a subdirectory, so we need to
|
||||
take this into account.
|
||||
|
||||
\snippet examples/tools/plugandpaint/mainwindow.cpp 6
|
||||
\snippet examples/tools/plugandpaint/mainwindow.cpp 7
|
||||
\snippet examples/tools/plugandpaint/mainwindow.cpp 8
|
||||
\snippet plugandpaint/mainwindow.cpp 6
|
||||
\snippet plugandpaint/mainwindow.cpp 7
|
||||
\snippet plugandpaint/mainwindow.cpp 8
|
||||
|
||||
We use QDir::entryList() to get a list of all files in that
|
||||
directory. Then we iterate over the result using \l foreach and
|
||||
@ -181,12 +181,12 @@
|
||||
|
||||
If QPluginLoader::instance() is non-null, we add it to the menus.
|
||||
|
||||
\snippet examples/tools/plugandpaint/mainwindow.cpp 9
|
||||
\snippet plugandpaint/mainwindow.cpp 9
|
||||
|
||||
At the end, we enable or disable the \uicontrol{Brush}, \uicontrol{Shapes},
|
||||
and \uicontrol{Filters} menus based on whether they contain any items.
|
||||
|
||||
\snippet examples/tools/plugandpaint/mainwindow.cpp 10
|
||||
\snippet plugandpaint/mainwindow.cpp 10
|
||||
|
||||
For each plugin (static or dynamic), we check which interfaces it
|
||||
implements using \l qobject_cast(). First, we try to cast the
|
||||
@ -195,7 +195,7 @@
|
||||
by \c brushes(). Then we do the same with the \c ShapeInterface
|
||||
and the \c FilterInterface.
|
||||
|
||||
\snippet examples/tools/plugandpaint/mainwindow.cpp 3
|
||||
\snippet plugandpaint/mainwindow.cpp 3
|
||||
|
||||
The \c aboutPlugins() slot is called on startup and can be
|
||||
invoked at any time through the \uicontrol{About Plugins} action. It
|
||||
@ -211,7 +211,7 @@
|
||||
plugin from which it comes from as the parent; this makes it
|
||||
convenient to get access to the plugin later.
|
||||
|
||||
\snippet examples/tools/plugandpaint/mainwindow.cpp 0
|
||||
\snippet plugandpaint/mainwindow.cpp 0
|
||||
|
||||
The \c changeBrush() slot is invoked when the user chooses one of
|
||||
the brushes from the \uicontrol{Brush} menu. We start by finding out
|
||||
@ -222,7 +222,7 @@
|
||||
identifying the brush. Next time the user draws on the paint
|
||||
area, \c PaintArea will use this brush.
|
||||
|
||||
\snippet examples/tools/plugandpaint/mainwindow.cpp 1
|
||||
\snippet plugandpaint/mainwindow.cpp 1
|
||||
|
||||
The \c insertShape() is invoked when the use chooses one of the
|
||||
shapes from the \uicontrol{Shapes} menu. We retrieve the QAction that
|
||||
@ -230,7 +230,7 @@
|
||||
QAction, and finally we call \c ShapeInterface::generateShape()
|
||||
to obtain a QPainterPath.
|
||||
|
||||
\snippet examples/tools/plugandpaint/mainwindow.cpp 2
|
||||
\snippet plugandpaint/mainwindow.cpp 2
|
||||
|
||||
The \c applyFilter() slot is similar: We retrieve the QAction
|
||||
that invoked the slot, then the \c FilterInterface associated to
|
||||
@ -243,12 +243,12 @@
|
||||
The \c PaintArea class contains some code that deals with \c
|
||||
BrushInterface, so we'll review it briefly.
|
||||
|
||||
\snippet examples/tools/plugandpaint/paintarea.cpp 0
|
||||
\snippet plugandpaint/paintarea.cpp 0
|
||||
|
||||
In \c setBrush(), we simply store the \c BrushInterface and the
|
||||
brush that are given to us by \c MainWindow.
|
||||
|
||||
\snippet examples/tools/plugandpaint/paintarea.cpp 1
|
||||
\snippet plugandpaint/paintarea.cpp 1
|
||||
|
||||
In the \l{QWidget::mouseMoveEvent()}{mouse move event handler},
|
||||
we call the \c BrushInterface::mouseMove() function on the
|
||||
@ -262,7 +262,7 @@
|
||||
and a list of plugin file names. It calls \c findPlugins()
|
||||
to fill the QTreeWdiget with information about the plugins:
|
||||
|
||||
\snippet examples/tools/plugandpaint/plugindialog.cpp 0
|
||||
\snippet plugandpaint/plugindialog.cpp 0
|
||||
|
||||
The \c findPlugins() is very similar to \c
|
||||
MainWindow::loadPlugins(). It uses QPluginLoader to access the
|
||||
@ -270,11 +270,11 @@
|
||||
populateTreeWidget() uses \l qobject_cast() to find out which
|
||||
interfaces are implemented by the plugins:
|
||||
|
||||
\snippet examples/tools/plugandpaint/plugindialog.cpp 1
|
||||
\snippet plugandpaint/plugindialog.cpp 1
|
||||
|
||||
\section1 Importing Static Plugins
|
||||
|
||||
The \l{tools/plugandpaintplugins/basictools}{Basic Tools} plugin
|
||||
The \l{plugandpaintplugins/basictools}{Basic Tools} plugin
|
||||
is built as a static plugin, to ensure that it is always
|
||||
available to the application. This requires using the
|
||||
Q_IMPORT_PLUGIN() macro somewhere in the application (in a \c
|
||||
@ -283,7 +283,7 @@
|
||||
For Plug & Paint, we have chosen to put Q_IMPORT_PLUGIN() in \c
|
||||
main.cpp:
|
||||
|
||||
\snippet examples/tools/plugandpaint/main.cpp 0
|
||||
\snippet plugandpaint/main.cpp 0
|
||||
|
||||
The argument to Q_IMPORT_PLUGIN() is the plugin's name, as
|
||||
specified with Q_EXPORT_PLUGIN2() in the \l{Exporting the
|
||||
@ -292,7 +292,7 @@
|
||||
In the \c .pro file, we need to specify the static library.
|
||||
Here's the project file for building Plug & Paint:
|
||||
|
||||
\snippet examples/tools/plugandpaint/plugandpaint.pro 0
|
||||
\snippet plugandpaint/plugandpaint.pro 0
|
||||
|
||||
The \c LIBS line variable specifies the library \c pnp_basictools
|
||||
located in the \c ../plugandpaintplugins/basictools directory.
|
||||
@ -306,16 +306,16 @@
|
||||
|
||||
This completes our review of the Plug & Paint application. At
|
||||
this point, you might want to take a look at the
|
||||
\l{tools/plugandpaintplugins/basictools}{Basic Tools} example
|
||||
\l{plugandpaintplugins/basictools}{Basic Tools} example
|
||||
plugin.
|
||||
*/
|
||||
|
||||
/*!
|
||||
\example tools/plugandpaintplugins/basictools
|
||||
\example plugandpaintplugins/basictools
|
||||
\title Plug & Paint Basic Tools Example
|
||||
|
||||
The Basic Tools example is a static plugin for the
|
||||
\l{tools/plugandpaint}{Plug & Paint} example. It provides a set
|
||||
\l{plugandpaint}{Plug & Paint} example. It provides a set
|
||||
of basic brushes, shapes, and filters. Through the Basic Tools
|
||||
example, we will review the four steps involved in writing a Qt
|
||||
plugin:
|
||||
@ -329,10 +329,10 @@
|
||||
|
||||
\section1 Declaration of the Plugin Class
|
||||
|
||||
\snippet examples/tools/plugandpaintplugins/basictools/basictoolsplugin.h 0
|
||||
\snippet plugandpaintplugins/basicbasictoolsplugin.h 0
|
||||
|
||||
We start by including \c interfaces.h, which defines the plugin
|
||||
interfaces for the \l{tools/plugandpaint}{Plug & Paint}
|
||||
interfaces for the \l{plugandpaint}{Plug & Paint}
|
||||
application. For the \c #include to work, we need to add an \c
|
||||
INCLUDEPATH entry to the \c .pro file with the path to Qt's \c
|
||||
examples/tools directory.
|
||||
@ -343,10 +343,10 @@
|
||||
The \c Q_INTERFACES() macro is necessary to tell \l{moc}, Qt's
|
||||
meta-object compiler, that the base classes are plugin
|
||||
interfaces. Without the \c Q_INTERFACES() macro, we couldn't use
|
||||
\l qobject_cast() in the \l{tools/plugandpaint}{Plug & Paint}
|
||||
\l qobject_cast() in the \l{plugandpaint}{Plug & Paint}
|
||||
application to detect interfaces.
|
||||
|
||||
\snippet examples/tools/plugandpaintplugins/basictools/basictoolsplugin.h 2
|
||||
\snippet plugandpaintplugins/basicbasictoolsplugin.h 2
|
||||
|
||||
In the \c public section of the class, we declare all the
|
||||
functions from the three interfaces.
|
||||
@ -356,23 +356,23 @@
|
||||
Let's now review the implementation of the \c BasicToolsPlugin
|
||||
member functions inherited from \c BrushInterface.
|
||||
|
||||
\snippet examples/tools/plugandpaintplugins/basictools/basictoolsplugin.cpp 0
|
||||
\snippet plugandpaintplugins/basicbasictoolsplugin.cpp 0
|
||||
|
||||
The \c brushes() function returns a list of brushes provided by
|
||||
this plugin. We provide three brushes: \uicontrol{Pencil}, \uicontrol{Air
|
||||
Brush}, and \uicontrol{Random Letters}.
|
||||
|
||||
\snippet examples/tools/plugandpaintplugins/basictools/basictoolsplugin.cpp 1
|
||||
\snippet plugandpaintplugins/basicbasictoolsplugin.cpp 1
|
||||
|
||||
On a mouse press event, we just call \c mouseMove() to draw the
|
||||
spot where the event occurred.
|
||||
|
||||
\snippet examples/tools/plugandpaintplugins/basictools/basictoolsplugin.cpp 2
|
||||
\snippet plugandpaintplugins/basicbasictoolsplugin.cpp 2
|
||||
|
||||
In \c mouseMove(), we start by saving the state of the QPainter
|
||||
and we compute a few variables that we'll need later.
|
||||
|
||||
\snippet examples/tools/plugandpaintplugins/basictools/basictoolsplugin.cpp 3
|
||||
\snippet plugandpaintplugins/basicbasictoolsplugin.cpp 3
|
||||
|
||||
Then comes the brush-dependent part of the code:
|
||||
|
||||
@ -394,14 +394,14 @@
|
||||
At the end, we restore the painter state to what it was upon
|
||||
entering the function and we return the bounding rectangle.
|
||||
|
||||
\snippet examples/tools/plugandpaintplugins/basictools/basictoolsplugin.cpp 4
|
||||
\snippet plugandpaintplugins/basicbasictoolsplugin.cpp 4
|
||||
|
||||
When the user releases the mouse, we do nothing and return an
|
||||
empty QRect.
|
||||
|
||||
\section1 Implementation of the Shape Interface
|
||||
|
||||
\snippet examples/tools/plugandpaintplugins/basictools/basictoolsplugin.cpp 5
|
||||
\snippet plugandpaintplugins/basicbasictoolsplugin.cpp 5
|
||||
|
||||
The plugin provides three shapes: \uicontrol{Circle}, \uicontrol{Star}, and
|
||||
\uicontrol{Text...}. The three dots after \uicontrol{Text} are there because
|
||||
@ -413,7 +413,7 @@
|
||||
distinguish between the internal shape name and the name used in
|
||||
the user interface.
|
||||
|
||||
\snippet examples/tools/plugandpaintplugins/basictools/basictoolsplugin.cpp 6
|
||||
\snippet plugandpaintplugins/basicbasictoolsplugin.cpp 6
|
||||
|
||||
The \c generateShape() creates a QPainterPath for the specified
|
||||
shape. If the shape is \uicontrol{Text}, we pop up a QInputDialog to
|
||||
@ -421,12 +421,12 @@
|
||||
|
||||
\section1 Implementation of the Filter Interface
|
||||
|
||||
\snippet examples/tools/plugandpaintplugins/basictools/basictoolsplugin.cpp 7
|
||||
\snippet plugandpaintplugins/basicbasictoolsplugin.cpp 7
|
||||
|
||||
The plugin provides three filters: \uicontrol{Invert Pixels}, \uicontrol{Swap
|
||||
RGB}, and \uicontrol{Grayscale}.
|
||||
|
||||
\snippet examples/tools/plugandpaintplugins/basictools/basictoolsplugin.cpp 8
|
||||
\snippet plugandpaintplugins/basicbasictoolsplugin.cpp 8
|
||||
|
||||
The \c filterImage() function takes a filter name and a QImage as
|
||||
parameters and returns an altered QImage. The first thing we do
|
||||
@ -444,7 +444,7 @@
|
||||
Q_EXPORT_PLUGIN2() macro to specify which class provides the
|
||||
plugin:
|
||||
|
||||
\snippet examples/tools/plugandpaintplugins/basictools/basictoolsplugin.cpp 9
|
||||
\snippet plugandpaintplugins/basicbasictoolsplugin.cpp 9
|
||||
|
||||
This line may appear in any \c .cpp file that is part of the
|
||||
plugin's source code.
|
||||
@ -453,7 +453,7 @@
|
||||
|
||||
Here's the project file for building the Basic Tools plugin:
|
||||
|
||||
\snippet examples/tools/plugandpaintplugins/basictools/basictools.pro 0
|
||||
\snippet plugandpaintplugins/basicbasictools.pro 0
|
||||
|
||||
The \c .pro file differs from typical \c .pro files in many
|
||||
respects. First, it starts with a \c TEMPLATE entry specifying \c
|
||||
@ -465,7 +465,7 @@
|
||||
|
||||
To make the plugin a static plugin, all that is required is to
|
||||
specify \c static in addition to \c plugin. The
|
||||
\l{tools/plugandpaintplugins/extrafilters}{Extra Filters} plugin,
|
||||
\l{plugandpaintplugins/extrafilters}{Extra Filters} plugin,
|
||||
which is compiled as a dynamic plugin, doesn't specify \c static
|
||||
in its \c .pro file.
|
||||
|
||||
@ -489,24 +489,24 @@
|
||||
*/
|
||||
|
||||
/*!
|
||||
\example tools/plugandpaintplugins/extrafilters
|
||||
\example plugandpaintplugins/extrafilters
|
||||
\title Plug & Paint Extra Filters Example
|
||||
|
||||
The Extra Filters example is a plugin for the
|
||||
\l{tools/plugandpaint}{Plug & Paint} example. It provides a set
|
||||
\l{plugandpaint}{Plug & Paint} example. It provides a set
|
||||
of filters in addition to those provided by the
|
||||
\l{tools/plugandpaintplugins/basictools}{Basic Tools} plugin.
|
||||
\l{plugandpaintplugins/basictools}{Basic Tools} plugin.
|
||||
|
||||
Since the approach is identical to
|
||||
\l{tools/plugandpaintplugins/basictools}{Basic Tools}, we won't
|
||||
\l{plugandpaintplugins/basictools}{Basic Tools}, we won't
|
||||
review the code here. The only part of interest is the
|
||||
\c .pro file, since Extra Filters is a dynamic plugin
|
||||
(\l{tools/plugandpaintplugins/basictools}{Basic Tools} is
|
||||
(\l{plugandpaintplugins/basictools}{Basic Tools} is
|
||||
linked statically into the Plug & Paint executable).
|
||||
|
||||
Here's the project file for building the Extra Filters plugin:
|
||||
|
||||
\snippet examples/tools/plugandpaintplugins/extrafilters/extrafilters.pro 0
|
||||
\snippet plugandpaintplugins/extrafilters/extrafilters.pro 0
|
||||
|
||||
The \c .pro file differs from typical \c .pro files in many
|
||||
respects. First, it starts with a \c TEMPLATE entry specifying \c
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
@ -26,7 +26,7 @@
|
||||
****************************************************************************/
|
||||
|
||||
/*!
|
||||
\example tools/regexp
|
||||
\example regexp
|
||||
\title Regular Expressions Example
|
||||
|
||||
The Regular Expressions (RegExp) example shows how regular expressions in Qt are
|
Before Width: | Height: | Size: 19 KiB After Width: | Height: | Size: 19 KiB |
@ -26,7 +26,7 @@
|
||||
****************************************************************************/
|
||||
|
||||
/*!
|
||||
\example tools/settingseditor
|
||||
\example settingseditor
|
||||
\title Settings Editor Example
|
||||
|
||||
The Settings Editor example shows how Qt's standard settings support is used in an
|
@ -43,7 +43,7 @@
|
||||
that has a list of words to help QCompleter complete words. This file
|
||||
contains the following:
|
||||
|
||||
\quotefile examples/tools/customcompleter/customcompleter.qrc
|
||||
\quotefile customcompleter/customcompleter.qrc
|
||||
|
||||
\section1 TextEdit Class Definition
|
||||
|
||||
@ -54,7 +54,7 @@
|
||||
contains a private function \c textUnderCursor() and a private instance
|
||||
of QCompleter, \c c.
|
||||
|
||||
\snippet examples/tools/customcompleter/textedit.h 0
|
||||
\snippet customcompleter/textedit.h 0
|
||||
|
||||
\section1 TextEdit Class Implementation
|
||||
|
||||
@ -63,11 +63,11 @@
|
||||
the \c TextEdit object, using the
|
||||
\l{QTextEdit::setPlainText()}{setPlainText()} function.
|
||||
|
||||
\snippet examples/tools/customcompleter/textedit.cpp 0
|
||||
\snippet customcompleter/textedit.cpp 0
|
||||
|
||||
In addition, \c TextEdit also includes a default destructor:
|
||||
|
||||
\snippet examples/tools/customcompleter/textedit.cpp 1
|
||||
\snippet customcompleter/textedit.cpp 1
|
||||
|
||||
The \c setCompleter() function accepts a \a completer and sets it up.
|
||||
We use \c{if (c)} to check if \c c has been initialized. If it has been
|
||||
@ -75,7 +75,7 @@
|
||||
the signal from the slot. This is to ensure that no previous completer
|
||||
object is still connected to the slot.
|
||||
|
||||
\snippet examples/tools/customcompleter/textedit.cpp 2
|
||||
\snippet customcompleter/textedit.cpp 2
|
||||
|
||||
We then instantiate \c c with \a completer and set it as \c{TextEdit}'s
|
||||
widget. The completion mode and case sensitivity are also set and then
|
||||
@ -84,7 +84,7 @@
|
||||
|
||||
The \c completer() function is a getter function that returns \c c.
|
||||
|
||||
\snippet examples/tools/customcompleter/textedit.cpp 3
|
||||
\snippet customcompleter/textedit.cpp 3
|
||||
|
||||
The completer pops up the options available, based on the contents of
|
||||
\e wordlist.txt, but the text cursor is responsible for filling in the
|
||||
@ -99,7 +99,7 @@
|
||||
completer's widget is \c TextEdit before using \c tc to insert the extra
|
||||
characters to complete the word.
|
||||
|
||||
\snippet examples/tools/customcompleter/textedit.cpp 4
|
||||
\snippet customcompleter/textedit.cpp 4
|
||||
|
||||
The figure below illustrates this process:
|
||||
|
||||
@ -116,13 +116,13 @@
|
||||
The \c textUnderCursor() function uses a QTextCursor, \c tc, to select a
|
||||
word under the cursor and return it.
|
||||
|
||||
\snippet examples/tools/customcompleter/textedit.cpp 5
|
||||
\snippet customcompleter/textedit.cpp 5
|
||||
|
||||
The \c TextEdit class reimplements \l{QWidget::focusInEvent()}
|
||||
{focusInEvent()} function, which is an event handler used to receive
|
||||
keyboard focus events for the widget.
|
||||
|
||||
\snippet examples/tools/customcompleter/textedit.cpp 6
|
||||
\snippet customcompleter/textedit.cpp 6
|
||||
|
||||
The \l{QAbstractScrollArea::keyPressEvent()}{keyPressEvent()} is
|
||||
reimplemented to ignore key events like Qt::Key_Enter, Qt::Key_Return,
|
||||
@ -131,12 +131,12 @@
|
||||
|
||||
If there is an active completer, we cannot process the shortcut, Ctrl+E.
|
||||
|
||||
\snippet examples/tools/customcompleter/textedit.cpp 7
|
||||
\snippet customcompleter/textedit.cpp 7
|
||||
|
||||
We also handle other modifiers and shortcuts for which we do not want the
|
||||
completer to respond to.
|
||||
|
||||
\snippet examples/tools/customcompleter/textedit.cpp 8
|
||||
\snippet customcompleter/textedit.cpp 8
|
||||
|
||||
Finally, we pop up the completer.
|
||||
|
||||
@ -147,7 +147,7 @@
|
||||
\c createMenu() and \c modelFromFile() as well as private instances of
|
||||
QCompleter and \c TextEdit.
|
||||
|
||||
\snippet examples/tools/customcompleter/mainwindow.h 0
|
||||
\snippet customcompleter/mainwindow.h 0
|
||||
|
||||
\section1 MainWindow Class Implementation
|
||||
|
||||
@ -157,31 +157,31 @@
|
||||
to populate the \c completer. The \c{MainWindow}'s central widget is set
|
||||
to \c TextEdit and its size is set to 500 x 300.
|
||||
|
||||
\snippet examples/tools/customcompleter/mainwindow.cpp 0
|
||||
\snippet customcompleter/mainwindow.cpp 0
|
||||
|
||||
The \c createMenu() function creates the necessary QAction objects needed
|
||||
for the "File" and "Help" menu and their \l{QAction::triggered()}
|
||||
{triggered()} signals are connected to the \c quit(), \c about(), and
|
||||
\c aboutQt() slots respectively.
|
||||
|
||||
\snippet examples/tools/customcompleter/mainwindow.cpp 1
|
||||
\snippet customcompleter/mainwindow.cpp 1
|
||||
|
||||
The \c modelFromFile() function accepts a \a fileName and attempts to
|
||||
extract the contents of this file into a QStringListModel. We display the
|
||||
Qt::WaitCursor when we are populating the QStringList, \c words, and
|
||||
restore the mouse cursor when we are done.
|
||||
|
||||
\snippet examples/tools/customcompleter/mainwindow.cpp 2
|
||||
\snippet customcompleter/mainwindow.cpp 2
|
||||
|
||||
The \c about() function provides a brief description about the Custom
|
||||
Completer example.
|
||||
|
||||
\snippet examples/tools/customcompleter/mainwindow.cpp 3
|
||||
\snippet customcompleter/mainwindow.cpp 3
|
||||
|
||||
\section1 \c main() Function
|
||||
|
||||
The \c main() function instantiates \c MainWindow and invokes the
|
||||
\l{QWidget::show()}{show()} function.
|
||||
|
||||
\snippet examples/tools/customcompleter/main.cpp 0
|
||||
\snippet customcompleter/main.cpp 0
|
||||
*/
|
||||
|
@ -56,7 +56,7 @@
|
||||
of information (a QString and a QStringList), each of which can be read
|
||||
using trivial getter functions:
|
||||
|
||||
\snippet examples/tools/customtype/message.h custom type definition
|
||||
\snippet 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 examples/tools/customtype/message.h custom type meta-type declaration
|
||||
\snippet 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 examples/tools/customtype/message.h custom type streaming operator
|
||||
\snippet 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 examples/tools/customtype/message.cpp Message class implementation
|
||||
\snippet customtype/message.cpp Message class implementation
|
||||
|
||||
The streaming operator is implemented in the following way:
|
||||
|
||||
\snippet examples/tools/customtype/message.cpp custom type streaming operator
|
||||
\snippet 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 examples/tools/customtype/message.cpp getter functions
|
||||
\snippet 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 examples/tools/customtype/main.cpp printing a custom type
|
||||
\snippet 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 examples/tools/customtype/main.cpp storing a custom value
|
||||
\snippet 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 examples/tools/customtype/main.cpp retrieving a custom value
|
||||
\snippet 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.
|
||||
|
@ -26,7 +26,7 @@
|
||||
****************************************************************************/
|
||||
|
||||
/*!
|
||||
\example tools/styleplugin
|
||||
\example styleplugin
|
||||
\title Style Plugin Example
|
||||
|
||||
This example shows how to create a plugin that extends Qt with a new
|
||||
@ -69,7 +69,7 @@
|
||||
\c SimpleStylePlugin inherits QStylePlugin and is the plugin
|
||||
class.
|
||||
|
||||
\snippet examples/tools/styleplugin/plugin/simplestyleplugin.h 0
|
||||
\snippet styleplugin/plugin/simplestyleplugin.h 0
|
||||
|
||||
\c keys() returns a list of style names that this plugin can
|
||||
create, while \c create() takes such a string and returns the
|
||||
@ -83,14 +83,14 @@
|
||||
|
||||
Here is the implementation of \c keys():
|
||||
|
||||
\snippet examples/tools/styleplugin/plugin/simplestyleplugin.cpp 0
|
||||
\snippet styleplugin/plugin/simplestyleplugin.cpp 0
|
||||
|
||||
Since this plugin only supports one style, we return a QStringList
|
||||
with the class name of that style.
|
||||
|
||||
Here is the \c create() function:
|
||||
|
||||
\snippet examples/tools/styleplugin/plugin/simplestyleplugin.cpp 1
|
||||
\snippet styleplugin/plugin/simplestyleplugin.cpp 1
|
||||
|
||||
Note that the key for style plugins are case insensitive.
|
||||
The case sensitivity varies from plugin to plugin, so you need to
|
||||
@ -98,7 +98,7 @@
|
||||
|
||||
\section1 The \c main() function
|
||||
|
||||
\snippet examples/tools/styleplugin/stylewindow/main.cpp 0
|
||||
\snippet styleplugin/stylewindow/main.cpp 0
|
||||
|
||||
Qt loads the available style plugins when the QApplication object
|
||||
is initialized. The QStyleFactory class knows about all styles and
|
||||
@ -110,7 +110,7 @@
|
||||
The \c SimpleStylePlugin lives in its own directory and have
|
||||
its own profile:
|
||||
|
||||
\snippet examples/tools/styleplugin/plugin/plugin.pro 0
|
||||
\snippet styleplugin/plugin/plugin.pro 0
|
||||
|
||||
In the plugin profile we need to set the lib template as we are
|
||||
building a shared library instead of an executable. We must also
|
Before Width: | Height: | Size: 5.1 KiB After Width: | Height: | Size: 5.1 KiB |
Before Width: | Height: | Size: 7.7 KiB After Width: | Height: | Size: 7.7 KiB |
Before Width: | Height: | Size: 25 KiB After Width: | Height: | Size: 25 KiB |
@ -26,7 +26,7 @@
|
||||
****************************************************************************/
|
||||
|
||||
/*!
|
||||
\example tools/treemodelcompleter
|
||||
\example treemodelcompleter
|
||||
\title Tree Model Completer Example
|
||||
|
||||
The Tree Model Completer example shows how to provide completion
|
||||
@ -45,7 +45,7 @@
|
||||
This file is embedded within the \e treemodelcompleter.qrc resource file,
|
||||
which contains the following:
|
||||
|
||||
\quotefile examples/tools/treemodelcompleter/treemodelcompleter.qrc
|
||||
\quotefile treemodelcompleter/treemodelcompleter.qrc
|
||||
|
||||
\section1 TreeModelCompleter Class Definition
|
||||
|
||||
@ -53,7 +53,7 @@
|
||||
constructors - one with \a parent as an argument and another with
|
||||
\a parent and \a model as arguments.
|
||||
|
||||
\snippet examples/tools/treemodelcompleter/treemodelcompleter.h 0
|
||||
\snippet treemodelcompleter/treemodelcompleter.h 0
|
||||
|
||||
The class reimplements the protected functions
|
||||
\l{QCompleter::splitPath()}{splitPath()} and
|
||||
@ -72,14 +72,14 @@
|
||||
parent while the second constructor constructs an object with a parent
|
||||
and a QAbstractItemModel, \a model.
|
||||
|
||||
\snippet examples/tools/treemodelcompleter/treemodelcompleter.cpp 0
|
||||
\snippet treemodelcompleter/treemodelcompleter.cpp 0
|
||||
\codeline
|
||||
\snippet examples/tools/treemodelcompleter/treemodelcompleter.cpp 1
|
||||
\snippet treemodelcompleter/treemodelcompleter.cpp 1
|
||||
|
||||
The \c separator() function is a getter function that returns the
|
||||
separator string.
|
||||
|
||||
\snippet examples/tools/treemodelcompleter/treemodelcompleter.cpp 2
|
||||
\snippet treemodelcompleter/treemodelcompleter.cpp 2
|
||||
|
||||
As mentioned earlier, the \c splitPath() function is reimplemented because
|
||||
the default implementation is more suited to QDirModel or list models. In
|
||||
@ -87,7 +87,7 @@
|
||||
matched at each level, we split it using QString::split() with \c sep as its
|
||||
separator.
|
||||
|
||||
\snippet examples/tools/treemodelcompleter/treemodelcompleter.cpp 3
|
||||
\snippet treemodelcompleter/treemodelcompleter.cpp 3
|
||||
|
||||
The \c pathFromIndex() function returns data for the completionRole() for a
|
||||
tree model. This function is reimplemented as its default implementation is
|
||||
@ -97,7 +97,7 @@
|
||||
accumulate the data. The function then returns a QStringList, \c dataList,
|
||||
using a separator to join objects of different levels.
|
||||
|
||||
\snippet examples/tools/treemodelcompleter/treemodelcompleter.cpp 4
|
||||
\snippet treemodelcompleter/treemodelcompleter.cpp 4
|
||||
|
||||
\section1 MainWindow Class Definition
|
||||
|
||||
@ -105,13 +105,13 @@
|
||||
custom slots: \c about(), \c changeCase(), \c changeMode(),
|
||||
\c highlight(), and \c updateContentsLabel().
|
||||
|
||||
\snippet examples/tools/treemodelcompleter/mainwindow.h 0
|
||||
\snippet treemodelcompleter/mainwindow.h 0
|
||||
|
||||
In addition, the class has two private functions, \c createMenu() and
|
||||
\c modelFromFile(), as well as private instances of QTreeView, QComboBox,
|
||||
QLabel, \c TreeModelCompleter and QLineEdit.
|
||||
|
||||
\snippet examples/tools/treemodelcompleter/mainwindow.h 1
|
||||
\snippet treemodelcompleter/mainwindow.h 1
|
||||
|
||||
\section1 MainWindow Class Implementation
|
||||
|
||||
@ -123,49 +123,49 @@
|
||||
{highlighted()} signal is connected to \c{MainWindow}'s \c highlight()
|
||||
slot.
|
||||
|
||||
\snippet examples/tools/treemodelcompleter/mainwindow.cpp 0
|
||||
\snippet treemodelcompleter/mainwindow.cpp 0
|
||||
|
||||
The QLabel objects \c modelLabel, \c modeLabel and \c caseLabel are
|
||||
instantiated. Also, the QComboBox objects, \c modeCombo and \c caseCombo,
|
||||
are instantiated and populated. By default, the \c{completer}'s mode is
|
||||
"Filtered Popup" and the case is insensitive.
|
||||
|
||||
\snippet examples/tools/treemodelcompleter/mainwindow.cpp 1
|
||||
\snippet treemodelcompleter/mainwindow.cpp 1
|
||||
\codeline
|
||||
\snippet examples/tools/treemodelcompleter/mainwindow.cpp 2
|
||||
\snippet treemodelcompleter/mainwindow.cpp 2
|
||||
|
||||
We use a QGridLayout to place all the objects in the \c MainWindow.
|
||||
|
||||
\snippet examples/tools/treemodelcompleter/mainwindow.cpp 3
|
||||
\snippet treemodelcompleter/mainwindow.cpp 3
|
||||
|
||||
The \c createMenu() function sets up the QAction objects required and
|
||||
adds them to the "File" menu and "Help" menu. The
|
||||
\l{QAction::triggered()}{triggered()} signals from these actions are
|
||||
connected to their respective slots.
|
||||
|
||||
\snippet examples/tools/treemodelcompleter/mainwindow.cpp 4
|
||||
\snippet treemodelcompleter/mainwindow.cpp 4
|
||||
|
||||
The \c changeMode() function accepts an \a index corresponding to the
|
||||
user's choice of completion mode and changes the \c{completer}'s mode
|
||||
accordingly.
|
||||
|
||||
\snippet examples/tools/treemodelcompleter/mainwindow.cpp 5
|
||||
\snippet treemodelcompleter/mainwindow.cpp 5
|
||||
|
||||
The \c about() function provides a brief description on the Tree Model
|
||||
Completer example.
|
||||
|
||||
\snippet examples/tools/treemodelcompleter/mainwindow.cpp 6
|
||||
\snippet treemodelcompleter/mainwindow.cpp 6
|
||||
|
||||
The \c changeCase() function alternates between \l{Qt::CaseSensitive}
|
||||
{Case Sensitive} and \l{Qt::CaseInsensitive}{Case Insensitive} modes,
|
||||
depending on the value of \a cs.
|
||||
|
||||
\snippet examples/tools/treemodelcompleter/mainwindow.cpp 7
|
||||
\snippet treemodelcompleter/mainwindow.cpp 7
|
||||
|
||||
\section1 \c main() Function
|
||||
|
||||
The \c main() function instantiates \c MainWindow and invokes the
|
||||
\l{QWidget::show()}{show()} function to display it.
|
||||
|
||||
\snippet examples/tools/treemodelcompleter/main.cpp 0
|
||||
\snippet treemodelcompleter/main.cpp 0
|
||||
*/
|
@ -26,7 +26,7 @@
|
||||
****************************************************************************/
|
||||
|
||||
/*!
|
||||
\example tools/undo
|
||||
\example undo
|
||||
\title Undo Framework
|
||||
|
||||
This example shows Qt's undo framework in action.
|
Before Width: | Height: | Size: 83 KiB After Width: | Height: | Size: 83 KiB |
@ -26,7 +26,7 @@
|
||||
****************************************************************************/
|
||||
|
||||
/*!
|
||||
\example tools/undoframework
|
||||
\example undoframework
|
||||
\title Undo Framework Example
|
||||
|
||||
This example shows how to implement undo/redo functionality
|
||||
@ -78,7 +78,7 @@
|
||||
|
||||
\section1 MainWindow Class Definition
|
||||
|
||||
\snippet examples/tools/undoframework/mainwindow.h 0
|
||||
\snippet undoframework/mainwindow.h 0
|
||||
|
||||
The \c MainWindow class maintains the undo stack, i.e., it creates
|
||||
\l{QUndoCommand}s and pushes and pops them from the stack when it
|
||||
@ -89,13 +89,13 @@
|
||||
|
||||
We will start with a look at the constructor:
|
||||
|
||||
\snippet examples/tools/undoframework/mainwindow.cpp 0
|
||||
\snippet undoframework/mainwindow.cpp 0
|
||||
|
||||
In the constructor, we set up the DiagramScene and QGraphicsView.
|
||||
|
||||
Here is the \c createUndoView() function:
|
||||
|
||||
\snippet examples/tools/undoframework/mainwindow.cpp 1
|
||||
\snippet undoframework/mainwindow.cpp 1
|
||||
|
||||
The QUndoView is a widget that display the text, which is set with
|
||||
the \l{QUndoCommand::}{setText()} function, for each QUndoCommand
|
||||
@ -103,11 +103,11 @@
|
||||
|
||||
Here is the \c createActions() function:
|
||||
|
||||
\snippet examples/tools/undoframework/mainwindow.cpp 2
|
||||
\snippet undoframework/mainwindow.cpp 2
|
||||
\codeline
|
||||
\snippet examples/tools/undoframework/mainwindow.cpp 3
|
||||
\snippet undoframework/mainwindow.cpp 3
|
||||
\dots
|
||||
\snippet examples/tools/undoframework/mainwindow.cpp 5
|
||||
\snippet undoframework/mainwindow.cpp 5
|
||||
|
||||
The \c createActions() function sets up all the examples actions
|
||||
in the manner shown above. The
|
||||
@ -120,12 +120,12 @@
|
||||
|
||||
Here is the \c createMenus() function:
|
||||
|
||||
\snippet examples/tools/undoframework/mainwindow.cpp 6
|
||||
\snippet undoframework/mainwindow.cpp 6
|
||||
|
||||
\dots
|
||||
\snippet examples/tools/undoframework/mainwindow.cpp 7
|
||||
\snippet undoframework/mainwindow.cpp 7
|
||||
\dots
|
||||
\snippet examples/tools/undoframework/mainwindow.cpp 8
|
||||
\snippet undoframework/mainwindow.cpp 8
|
||||
|
||||
We have to use the QMenu \c aboutToShow() and \c aboutToHide()
|
||||
signals since we only want \c deleteAction to be enabled when we
|
||||
@ -133,14 +133,14 @@
|
||||
|
||||
Here is the \c itemMoved() slot:
|
||||
|
||||
\snippet examples/tools/undoframework/mainwindow.cpp 9
|
||||
\snippet undoframework/mainwindow.cpp 9
|
||||
|
||||
We simply push a MoveCommand on the stack, which calls \c redo()
|
||||
on it.
|
||||
|
||||
Here is the \c deleteItem() slot:
|
||||
|
||||
\snippet examples/tools/undoframework/mainwindow.cpp 10
|
||||
\snippet undoframework/mainwindow.cpp 10
|
||||
|
||||
An item must be selected to be deleted. We need to check if it is
|
||||
selected as the \c deleteAction may be enabled even if an item is
|
||||
@ -149,9 +149,9 @@
|
||||
|
||||
Here is the \c itemMenuAboutToShow() and itemMenuAboutToHide() slots:
|
||||
|
||||
\snippet examples/tools/undoframework/mainwindow.cpp 11
|
||||
\snippet undoframework/mainwindow.cpp 11
|
||||
\codeline
|
||||
\snippet examples/tools/undoframework/mainwindow.cpp 12
|
||||
\snippet undoframework/mainwindow.cpp 12
|
||||
|
||||
We implement \c itemMenuAboutToShow() and \c itemMenuAboutToHide()
|
||||
to get a dynamic item menu. These slots are connected to the
|
||||
@ -160,28 +160,28 @@
|
||||
|
||||
Here is the \c addBox() slot:
|
||||
|
||||
\snippet examples/tools/undoframework/mainwindow.cpp 13
|
||||
\snippet undoframework/mainwindow.cpp 13
|
||||
|
||||
The \c addBox() function creates an AddCommand and pushes it on
|
||||
the undo stack.
|
||||
|
||||
Here is the \c addTriangle() sot:
|
||||
|
||||
\snippet examples/tools/undoframework/mainwindow.cpp 14
|
||||
\snippet undoframework/mainwindow.cpp 14
|
||||
|
||||
The \c addTriangle() function creates an AddCommand and pushes it
|
||||
on the undo stack.
|
||||
|
||||
Here is the implementation of \c about():
|
||||
|
||||
\snippet examples/tools/undoframework/mainwindow.cpp 15
|
||||
\snippet undoframework/mainwindow.cpp 15
|
||||
|
||||
The about slot is triggered by the \c aboutAction and displays an
|
||||
about box for the example.
|
||||
|
||||
\section1 AddCommand Class Definition
|
||||
|
||||
\snippet examples/tools/undoframework/commands.h 2
|
||||
\snippet undoframework/commands.h 2
|
||||
|
||||
The \c AddCommand class adds DiagramItem graphics items to the
|
||||
DiagramScene.
|
||||
@ -190,32 +190,32 @@
|
||||
|
||||
We start with the constructor:
|
||||
|
||||
\snippet examples/tools/undoframework/commands.cpp 7
|
||||
\snippet undoframework/commands.cpp 7
|
||||
|
||||
We first create the DiagramItem to add to the DiagramScene. The
|
||||
\l{QUndoCommand::}{setText()} function let us set a QString that
|
||||
describes the command. We use this to get custom messages in the
|
||||
QUndoView and in the menu of the main window.
|
||||
|
||||
\snippet examples/tools/undoframework/commands.cpp 8
|
||||
\snippet undoframework/commands.cpp 8
|
||||
|
||||
\c undo() removes the item from the scene.
|
||||
|
||||
\snippet examples/tools/undoframework/commands.cpp 9
|
||||
\snippet undoframework/commands.cpp 9
|
||||
|
||||
We set the position of the item as we do not do this in the
|
||||
constructor.
|
||||
|
||||
\section1 DeleteCommand Class Definition
|
||||
|
||||
\snippet examples/tools/undoframework/commands.h 1
|
||||
\snippet undoframework/commands.h 1
|
||||
|
||||
The DeleteCommand class implements the functionality to remove an
|
||||
item from the scene.
|
||||
|
||||
\section1 DeleteCommand Class Implementation
|
||||
|
||||
\snippet examples/tools/undoframework/commands.cpp 4
|
||||
\snippet undoframework/commands.cpp 4
|
||||
|
||||
We know that there must be one selected item as it is not possible
|
||||
to create a DeleteCommand unless the item to be deleted is
|
||||
@ -223,17 +223,17 @@
|
||||
The item must be unselected if it is inserted back into the
|
||||
scene.
|
||||
|
||||
\snippet examples/tools/undoframework/commands.cpp 5
|
||||
\snippet undoframework/commands.cpp 5
|
||||
|
||||
The item is simply reinserted into the scene.
|
||||
|
||||
\snippet examples/tools/undoframework/commands.cpp 6
|
||||
\snippet undoframework/commands.cpp 6
|
||||
|
||||
The item is removed from the scene.
|
||||
|
||||
\section1 MoveCommand Class Definition
|
||||
|
||||
\snippet examples/tools/undoframework/commands.h 0
|
||||
\snippet undoframework/commands.h 0
|
||||
|
||||
The \l{QUndoCommand::}{mergeWith()} is reimplemented to make
|
||||
consecutive moves of an item one MoveCommand, i.e, the item will
|
||||
@ -244,20 +244,20 @@
|
||||
|
||||
The constructor of MoveCommand looks like this:
|
||||
|
||||
\snippet examples/tools/undoframework/commands.cpp 0
|
||||
\snippet undoframework/commands.cpp 0
|
||||
|
||||
We save both the old and new positions for undo and redo
|
||||
respectively.
|
||||
|
||||
\snippet examples/tools/undoframework/commands.cpp 2
|
||||
\snippet undoframework/commands.cpp 2
|
||||
|
||||
We simply set the items old position and update the scene.
|
||||
|
||||
\snippet examples/tools/undoframework/commands.cpp 3
|
||||
\snippet undoframework/commands.cpp 3
|
||||
|
||||
We set the item to its new position.
|
||||
|
||||
\snippet examples/tools/undoframework/commands.cpp 1
|
||||
\snippet undoframework/commands.cpp 1
|
||||
|
||||
Whenever a MoveCommand is created, this function is called to
|
||||
check if it should be merged with the previous command. It is the
|
||||
@ -271,7 +271,7 @@
|
||||
|
||||
\section1 DiagramScene Class Definition
|
||||
|
||||
\snippet examples/tools/undoframework/diagramscene.h 0
|
||||
\snippet undoframework/diagramscene.h 0
|
||||
|
||||
The DiagramScene implements the functionality to move a
|
||||
DiagramItem with the mouse. It emits a signal when a move is
|
||||
@ -283,7 +283,7 @@
|
||||
|
||||
The \c main() function of the program looks like this:
|
||||
|
||||
\snippet examples/tools/undoframework/main.cpp 0
|
||||
\snippet undoframework/main.cpp 0
|
||||
|
||||
We draw a grid in the background of the DiagramScene, so we use a
|
||||
resource file. The rest of the function creates the \c MainWindow and
|
Before Width: | Height: | Size: 18 KiB After Width: | Height: | Size: 18 KiB |
@ -205,7 +205,7 @@
|
||||
supported formats using the \l{The foreach Keyword}{foreach keyword}.
|
||||
This keyword has the following format:
|
||||
|
||||
\snippet doc/src/snippets/code/doc_src_examples_dropsite.qdoc 0
|
||||
\snippet code/doc_src_examples_dropsite.qdoc 0
|
||||
|
||||
In our example, \c format is the \a variable and the \a container is a
|
||||
QStringList, obtained from \c mimeData->formats().
|
Before Width: | Height: | Size: 116 KiB After Width: | Height: | Size: 116 KiB |
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 14 KiB |
Before Width: | Height: | Size: 18 KiB After Width: | Height: | Size: 18 KiB |
Before Width: | Height: | Size: 45 KiB After Width: | Height: | Size: 45 KiB |
Before Width: | Height: | Size: 9.6 KiB After Width: | Height: | Size: 9.6 KiB |
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
@ -27,7 +27,7 @@
|
||||
****************************************************************************/
|
||||
|
||||
/*!
|
||||
\example widgets/mousebuttons/buttontester
|
||||
\example widgets/mousebuttons
|
||||
\title Mouse Button Tester
|
||||
|
||||
\brief The 'Mouse Button Tester' example demonstrates how to reimplement
|
||||
@ -38,21 +38,21 @@
|
||||
sending text shortcuts for certain games. With such a mouse, no mouse
|
||||
button events occur: The "mouse" sends keystrokes, and the
|
||||
'Mouse Button Tester' Window will not see the event. Receiving no event,
|
||||
it will not repaint the Window with new text describing a \button event.
|
||||
it will not repaint the Window with new text describing a button event.
|
||||
|
||||
And so, in addition to it's use as Qt example code, the program may be
|
||||
useful s a mouse device tester. Note that there is another example
|
||||
muouse buttons example which provides the same function, written in QML.
|
||||
mouse buttons example which provides the same function, written in QML.
|
||||
|
||||
This program (the Widget-based example) consists of three classes,
|
||||
in addition to the main() parent program:
|
||||
|
||||
\list
|
||||
\o \c A QPushButton, "Quit".
|
||||
\o \c ButtonTester. This is derived from Qt's TextArea class, for
|
||||
\li \c A QPushButton, "Quit".
|
||||
\li \c ButtonTester. This is derived from Qt's TextArea class, for
|
||||
purpose of customizing/re-implementing the mouse and wheel event
|
||||
member functions.
|
||||
\o \c A simple QVBoxLayout layout.
|
||||
\li \c A simple QVBoxLayout layout.
|
||||
\endlist
|
||||
|
||||
First we will review the main program, with it's layout and "Quit"
|
||||
@ -66,7 +66,7 @@
|
||||
class would result in the destructor of that second class being
|
||||
called twice. This "Quit" Button uses the traditional Signal/Slot
|
||||
connection to invoke termination of the QApp, which will properly destroy
|
||||
its child classes \before terminating itself.
|
||||
its child classes before terminating itself.
|
||||
|
||||
The remainder of the main() program is concerned with defining the layout,
|
||||
and applying a minimum size to the customized ButtonTester.
|
||||
@ -90,5 +90,5 @@
|
||||
this automatically, but it is better programming practice to explicitly
|
||||
invoke the function.)
|
||||
|
||||
\image widgets/mousebutton-buttontester.png
|
||||
\image mousebutton-buttontester.png
|
||||
*/
|
@ -80,7 +80,7 @@
|
||||
\c MainWindow inherits from QWidget and acts as the top level widget of the
|
||||
application.
|
||||
|
||||
\snippet examples/widgets/orientation/mainwindow.h 0
|
||||
\snippet widgets/orientation/mainwindow.h 0
|
||||
|
||||
The \c resizeEvent() method is re-implemented, and used to check which
|
||||
UI to show. The \c onRadioButtonClicked() slot is connected to the
|
||||
@ -94,19 +94,19 @@
|
||||
In the constructor, the widgets that will hold the UIs are created and set
|
||||
up.
|
||||
|
||||
\snippet examples/widgets/orientation/mainwindow.cpp 0
|
||||
\snippet widgets/orientation/mainwindow.cpp 0
|
||||
|
||||
Since the exit buttons on the layouts are different from each other, both
|
||||
of them have to have their \c clicked() signal connected to the \c close()
|
||||
slot of the main widget. The first image is also made current with the call
|
||||
to \c onRadioButtonClicked().
|
||||
|
||||
\snippet examples/widgets/orientation/mainwindow.cpp 1
|
||||
\snippet widgets/orientation/mainwindow.cpp 1
|
||||
|
||||
On the Maemo platform, windows are stuck in landscape mode by default. The
|
||||
application has to explicitly say that rotation is supported.
|
||||
|
||||
\snippet examples/widgets/orientation/mainwindow.cpp 2
|
||||
\snippet widgets/orientation/mainwindow.cpp 2
|
||||
|
||||
The \c resizeEvent() is called when the main window is first created, and
|
||||
also whenever the window has been resized. If the window is shown in
|
||||
@ -118,7 +118,7 @@
|
||||
(possibly transposed) size of the window. Depending on the orientation, one
|
||||
widget is made visible and the other invisible.
|
||||
|
||||
\snippet examples/widgets/orientation/mainwindow.cpp 3
|
||||
\snippet widgets/orientation/mainwindow.cpp 3
|
||||
|
||||
When the user selects one of the radio buttons in the landscape UI, the
|
||||
current image is changed. The image is displayed by specifying the
|
||||
@ -126,7 +126,7 @@
|
||||
\c landscape have a \c choiceWidget of their own, the change has to be
|
||||
reflected in both instances.
|
||||
|
||||
\snippet examples/widgets/orientation/mainwindow.cpp 4
|
||||
\snippet widgets/orientation/mainwindow.cpp 4
|
||||
|
||||
Synchronizing both UIs like this might become unfeasible when there are
|
||||
many things that can change. In that case it is better to make use of the
|
||||
@ -139,5 +139,5 @@
|
||||
|
||||
The main function creates a \c MainWindow instance and shows it full
|
||||
screen.
|
||||
\snippet examples/widgets/orientation/main.cpp 0
|
||||
\snippet widgets/orientation/main.cpp 0
|
||||
*/
|