diff options
10 files changed, 24 insertions, 22 deletions
diff --git a/examples/interfaceframework/qface-climate/doc/src/qface-climate.qdoc b/examples/interfaceframework/qface-climate/doc/src/qface-climate.qdoc index cac8f585..c045ddc2 100644 --- a/examples/interfaceframework/qface-climate/doc/src/qface-climate.qdoc +++ b/examples/interfaceframework/qface-climate/doc/src/qface-climate.qdoc @@ -214,7 +214,7 @@ implementation of our module and its interface. In this case, we use the \c frontend template, that generates a class derived from \c {QIfAbstractZonedFeature} including all the specified properties. The generated library uses the \l {Dynamic Backend System} from QtInterfaceFramework, providing an easy way to change the behavior -implementations. For more details, see \l {Backend Simulator Plugin}. +implementations. For more details, see \l {Back End Simulator Plugin}. To call the autogenerator for our shared library, it needs to be integrated into the build system. diff --git a/examples/interfaceframework/qface-tutorial/doc/src/qface-tutorial.qdoc b/examples/interfaceframework/qface-tutorial/doc/src/qface-tutorial.qdoc index 031f0143..22617251 100644 --- a/examples/interfaceframework/qface-tutorial/doc/src/qface-tutorial.qdoc +++ b/examples/interfaceframework/qface-tutorial/doc/src/qface-tutorial.qdoc @@ -129,11 +129,11 @@ \printto install First \e find_package needs to be used to get all needed libraries into the CMake build system. - A new library is defined with \l {qt6_add_library} and, using CMake target_properties, the + A new library is defined with \l {qt_add_library} and, using CMake target_properties, the output name, as well as the output directory are set. As we need to link to this library in the future, it is easier to put the file into the upper directory. - By calling the \l {qt6_ifcodegen_extend_target} function, the \c autogenerator is called and the + By calling the \l {qt_ifcodegen_extend_target} function, the \c autogenerator is called and the previously defined library is extended with the generated files. The input file is specified using the \e IDL_FILES argument. See \l{Build System Integration} for more information. @@ -161,7 +161,7 @@ should be generated from a QFace file. Using qmake, the template needs to be defined by the \c IFCODEGEN_TEMPLATE variable. If it is not defined, it defaults to the "frontend" template. In CMake the template needs to be specified using the \c TEMPLATE argument of - \l {qt6_ifcodegen_extend_target} and friends. + \l {qt_ifcodegen_extend_target} and friends. For more details on these templates, see \l{Use the Generator}. In short, the "frontend" template generates: @@ -355,7 +355,7 @@ is a simulation back end. When a "production" back end is available, it is preferred over the "simulation" one. For more information, see \l{Dynamic Backend System}. - As before, the Interface Framework Generator is called by using the \l{qt6_ifcodegen_extend_target} + As before, the Interface Framework Generator is called by using the \l{qt_ifcodegen_extend_target} function, this time setting "backend_simulator" as the \c TEMPLATE. \e qmake: @@ -489,7 +489,7 @@ Unlike all our previous generator calls we don't extend a previously defined target, but import the generated code into CMake and pass it to the \l {qt_add_qml_module} function. - The \l {qt6_ifcoegen_import_variables} function will call the generator and export variables + The \l {qt_ifcodegen_import_variables} function will call the generator and export variables starting with \e CLUSTER as prefix to the current CMake scope. Those variables reference auto-generated code, but also expose other information like the QML import URI. @@ -711,9 +711,10 @@ The name of the plugin doesn't end with "_simulation" to indicate that this is a "production" back end. The template is now changed to "backend_qtro" to generate a back end that uses - \l{Qt Remote Objects Replicas} to connect to a \l{Qt Remote Objects Source} that provides the values. In - addition to a back end based on QtRemoteObject, we also need a server based on QtRemoteObject . This - part can also be auto-generated using the Interface Framework Generator in a similar fashion: + \l{Qt Remote Objects Replica}{Qt Remote Objects Replicas} to connect to a \l{Qt Remote Objects Source} + that provides the values. In addition to a back end based on QtRemoteObject, we also need a + server based on QtRemoteObject . This part can also be auto-generated using the Interface + Framework Generator in a similar fashion: \e CMake: @@ -727,7 +728,7 @@ \printto RESOURCES Because we'd like to generate a server binary, the qmake \c TEMPLATE needs to be set to "app" - instead of "lib", in CMake we use \l {qt_add_exectuable} instead. Similar to the plugin, the + instead of "lib", in CMake we use \l {qt_add_executable} instead. Similar to the plugin, the server also needs to link against our library to give it access to the defined enums, structures, and other types. The template we use to generate a simulation server is called "server_qtro_simulator". @@ -802,7 +803,7 @@ Let's start with a build system file for our back end. This is very similar to previous files, but it doesn't use the Interface Framework Generator. Instead, it uses \c DBUS_INTERFACES for qmake to auto-generate some client code which sends and receives messages over D-Bus. - In the CMake case the \l {qt6_add_dbus_interface} function is used to do the same. + In the CMake case the \l {qt_add_dbus_interface} function is used to do the same. Now, we need to define an entry point for our plugin. This plugin class needs to derive from QIfServiceInterface and implement two functions: diff --git a/src/ifvehiclefunctions/doc/src/qtifvehiclefunctions.qdoc b/src/ifvehiclefunctions/doc/src/qtifvehiclefunctions.qdoc index 009f6022..1d3fa03f 100644 --- a/src/ifvehiclefunctions/doc/src/qtifvehiclefunctions.qdoc +++ b/src/ifvehiclefunctions/doc/src/qtifvehiclefunctions.qdoc @@ -146,10 +146,10 @@ } \endcode - When the top-level component has been completed, the \l isValid property of the feature elements - can be used to determine if any of the back ends are missing. In some situations this is expected - behavior; the isValid property can be used to enable or disable parts of the user - interface. + When the top-level component has been completed, the \l {AbstractFeature::}{isValid} property + of the feature elements can be used to determine if any of the back ends are missing. In some + situations this is expected behavior; the isValid property can be used to enable or disable + parts of the user interface. \code Component.onCompleted: { diff --git a/src/interfaceframework/doc/qtinterfaceframework-project.qdocconf b/src/interfaceframework/doc/qtinterfaceframework-project.qdocconf index d55c2b26..5c27db86 100644 --- a/src/interfaceframework/doc/qtinterfaceframework-project.qdocconf +++ b/src/interfaceframework/doc/qtinterfaceframework-project.qdocconf @@ -64,7 +64,7 @@ qhp.QtInterfaceFramework.subprojects.examples.sortPages = true tagfile = interfaceframework.tags -depends += qtcore qtdbus qtwidgets qtdoc qtquick qtqml qtremoteobjects +depends += qtcore qtdbus qtwidgets qtdoc qtcmake qtquick qtqml qtremoteobjects navigation.landingpage = "Qt Interface Framework" navigation.cppclassespage = "Qt Interface Framework C++ Classes" diff --git a/src/interfaceframework/doc/src/ifcodegen/cmake-macros.qdoc b/src/interfaceframework/doc/src/ifcodegen/cmake-macros.qdoc index e0dfc862..2b47d6c1 100644 --- a/src/interfaceframework/doc/src/ifcodegen/cmake-macros.qdoc +++ b/src/interfaceframework/doc/src/ifcodegen/cmake-macros.qdoc @@ -108,7 +108,7 @@ can be found. The other IDL files still need to be generated and built on their to. By default all log messages generated by \a {ifcodegen} are discarded. To show them you can use the -\c VERBOSE argument, set the \l {IFCODEGEN_VERBOSE} variable or use set \l {CMAKE_MESSAGE_LOG_LEVEL} +\c VERBOSE argument, set the \l {IFCODEGEN_VERBOSE} variable or use set \c {CMAKE_MESSAGE_LOG_LEVEL} to \c VERBOSE. For more details on the generator's command line arguments, see \l {Use the Generator}. diff --git a/src/interfaceframework/doc/src/ifcodegen/filter-reference.qdoc b/src/interfaceframework/doc/src/ifcodegen/filter-reference.qdoc index aa0fa336..271c793c 100644 --- a/src/interfaceframework/doc/src/ifcodegen/filter-reference.qdoc +++ b/src/interfaceframework/doc/src/ifcodegen/filter-reference.qdoc @@ -31,7 +31,7 @@ \page filter-reference.html \title Filter Reference \previouspage Use the Generator -\nextpage Qmake Integration +\nextpage Build System Integration In addition to the built-in Jinja filters listed \l {http://jinja.pocoo.org/docs/2.9/templates/#list-of-builtin-filters} {here}, the following diff --git a/src/interfaceframework/doc/src/ifcodegen/generator-usage.qdoc b/src/interfaceframework/doc/src/ifcodegen/generator-usage.qdoc index 5662d134..c57e29a2 100644 --- a/src/interfaceframework/doc/src/ifcodegen/generator-usage.qdoc +++ b/src/interfaceframework/doc/src/ifcodegen/generator-usage.qdoc @@ -65,7 +65,7 @@ Adds the given path to the list of search paths. All directories in this list are scanned for generation templates (identified by the \l{Generation YAML}). The identified templates can be selected with the - \l{\target template}{--template option}. + \l{template}{--template option}. \row \target template \li \c -t, \c --template diff --git a/src/interfaceframework/doc/src/ifcodegen/ifcodegen.qdoc b/src/interfaceframework/doc/src/ifcodegen/ifcodegen.qdoc index 87b0543f..941c13a8 100644 --- a/src/interfaceframework/doc/src/ifcodegen/ifcodegen.qdoc +++ b/src/interfaceframework/doc/src/ifcodegen/ifcodegen.qdoc @@ -29,6 +29,7 @@ /*! \page ifcodegen.html \title Qt Interface Framework Generator +\target ifcodegen \keyword QFace Qt Interface Framework provides a way for you to describe interfaces using its own Interface Definition Language diff --git a/src/interfaceframework/doc/src/models.qdoc b/src/interfaceframework/doc/src/models.qdoc index 152a0e9b..236c3737 100644 --- a/src/interfaceframework/doc/src/models.qdoc +++ b/src/interfaceframework/doc/src/models.qdoc @@ -33,7 +33,7 @@ \nextpage Qt Interface Framework Query Language To interact with lists in Qt applications you would use Qt's -\l{ListView classes}. These are based on the Model-View-Controller (MVC) pattern. +\l{The Model/View Classes}{ListView classes}. These are based on the Model-View-Controller (MVC) pattern. Similarly, QtInterfaceFramework has the following classes that support this use case, for you to provide your own models: diff --git a/src/interfaceframework/doc/src/qtif.qdoc b/src/interfaceframework/doc/src/qtif.qdoc index 44a45191..fa2eb314 100644 --- a/src/interfaceframework/doc/src/qtif.qdoc +++ b/src/interfaceframework/doc/src/qtif.qdoc @@ -39,8 +39,8 @@ Qt Interface Framework consists of three types of building blocks: \list - \li The \l{Qt Interface Framework Core}{core module} provides base classes - and common code for all APIs created by you, the developer. + \li The \l{Qt Interface Framework Core C++ Classes}{core module} provides + base classes and common code for all APIs created by you, the developer. \li The user created API definitions like a climate API or a mediaplayer API. Each of these APIs is the second building block called \e Features, which define the API exposed to the application developer. |