summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJuergen Bocklage-Ryannel <juergen.bocklage-ryannel@pelagicore.com>2017-03-15 11:52:35 +0100
committerJuergen Bocklage-Ryannel <juergen.bocklage-ryannel@pelagicore.com>2017-03-15 11:52:35 +0100
commited428a06bbd665e4fe97ffc02a81620c5676e424 (patch)
tree927030a3f278ab88e4782703e107a04be9d19371
parent7159223d1656abfd3ea891469ae5090f481b5e81 (diff)
parent1b3880de3a3f4b4a744ec8d7c6772b2287a1acb3 (diff)
downloadqtivi-qface-ed428a06bbd665e4fe97ffc02a81620c5676e424.tar.gz
Merge branch 'release/1.1b2'1.1b2
-rw-r--r--README.md1
-rw-r--r--docs/grammar.rst4
-rw-r--r--docs/motivation.rst19
-rw-r--r--docs/qtcpp.rst8
-rw-r--r--docs/qtqml.rst6
-rw-r--r--docs/usage.rst6
-rw-r--r--qface/__about__.py2
7 files changed, 23 insertions, 23 deletions
diff --git a/README.md b/README.md
index 1760a7f..6b56c0e 100644
--- a/README.md
+++ b/README.md
@@ -2,6 +2,7 @@
[![Build Status](https://travis-ci.org/Pelagicore/qface.svg?branch=develop)](https://travis-ci.org/Pelagicore/qface)
[![Documentation Status](https://readthedocs.org/projects/qface/badge/?version=latest)](http://qface.readthedocs.io/en/latest/?badge=latest)
+[![Chat at https://gitter.im/qmlbook/qface](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/qmlbook/qface?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
QFace is a generator framework based on a common modern IDL. It is not a generator as such but enforces a common IDL format and provides a library to write your own generator. It is actually very easy to create your own generator and generate your custom solution based on your needs from the same IDL.
diff --git a/docs/grammar.rst b/docs/grammar.rst
index c5acd91..b8abb74 100644
--- a/docs/grammar.rst
+++ b/docs/grammar.rst
@@ -2,7 +2,7 @@
QFace Grammar
=============
-QFace (Qt interface language) is an IDL to define an interface. In general it is modeled to define an interface between Qt QML and C++. The QFace syntax is flexible enough also to be used in other context.
+QFace (Qt interface language) is an Interface Description Languge (IDL). While it is primarily designed to define an interface between Qt, QML and C++, it is intended to be flexible enough also to be used in other contexts.
.. code-block:: html
@@ -33,7 +33,7 @@ A QFace document always describes one module. Each document can contain one or m
Module
======
-A module is identified name. A module should be normally a URI where all parts are lowercase (e.g. `entertainment.tuner`). A module can import other modules. This is used to ensure that dependencies are declared inside the QFace file.
+A module is identified name. A module should be normally a URI where all parts are lowercase (e.g. `entertainment.tuner`). A module may import other modules with the primary purpose being to ensure that dependencies are declared inside the QFace file.
Types
-----
diff --git a/docs/motivation.rst b/docs/motivation.rst
index fcd19ba..2b54801 100644
--- a/docs/motivation.rst
+++ b/docs/motivation.rst
@@ -2,14 +2,14 @@
Motivation
==========
-QFace is an attempt to establish one interface description language with an easy to use code generator framework. QFace as an interface description language is Qt friendly but not limited to Qt. The hope is that many projects can agree on this interface language and many interesting generators will be created and we all can learn from how other projects generate code from the same IDL.
+QFace is an attempt to establish one interface description language with an easy to use code generator framework. While QFace as an interface description language is Qt friendly, it is not limited to Qt. The hope is that many projects can agree on this interface language and many interesting generators will be created and we all can learn from how other projects generate code from the same IDL.
The IDL
=======
-The IDL uses common API concept such as modules, interfaces, properties, structs and enums/flags. Additional it knows about lists and models. A list is an array of primitive or complex types. A model is an indicator for large data sets which are typical used via a defined interface or via pagination.
+The IDL uses common API concept such as modules, interfaces, properties, structs and enums/flags. Additionally it knows about lists and models. A list is an array of primitive or complex types. A model is an indicator for large data sets which are typical used via a defined interface or via pagination.
-... code-block:: js
+.. code-block:: js
module org.example 1.0
@@ -25,7 +25,6 @@ The IDL uses common API concept such as modules, interfaces, properties, structs
}
-
The data types provided by QFace can be divided into primitive and complex types:
Primitive Types
@@ -63,7 +62,7 @@ Even inside on e technolgy there are often discussions about how an interface sh
Large Projects
==============
-In larger projects there is the need to interface a large set of operating services and make them available to QML. It is less about defining new visual items in C++ more about creating an abstraction of a service and make it available to the HMI developer inside QML.
+In larger projects there is the need to make available to QML a large set of operating services. It is less about defining new visual items in C++, more about creating an abstraction of a service and make it available to the HMI developer inside QML.
This can be a challenge when you create many of these plugins and in the middle of the project you figure out you have issues with your current design. Or if the customer in the next project wants to use a different HMI technology. All the knowledge is inside these plugins.
@@ -72,18 +71,18 @@ With QFace these companies can be certain that QFace does not lock them into the
Remote Services
===============
-Some projects use network communication to communicate from the HMI to the services, which might run on a different process or event networked device. QFace was not designed for remote services, as it does not define any storage types (e.g. int32, int16, int64) it knows only an int and does not define how large the int shall be. For this QFace need to rely on the author of the generators to have a defined protocol to exchange data.
+Some projects use network communication to communicate from the HMI to the services, which might run on a different process or event networked device. QFace was not designed for remote services as it does not define any storage types (e.g. int32, int16, int64), it only knows an int and does not define how large the int shall be. For this QFace needs to rely on the author of the generators to have a defined protocol to exchange data.
Complex APIs
============
-QFace is by design limited by its features. QFace shall be easy to use and the syntax easy to remember, so that also none experts can write their interface files.
+QFace is purposely designed to have limited features. The goal is to make QFace easy to use with an easy to remember syntax so that you don't need to be an expert to write interface files.
-QFace does not suppot unions or extending from other interfaces or that a struct extends other structs. If you look for these features than QFace is probably the wring choice.
+QFace does not suppot unions or extending from other interfaces or that a struct extends other structs. If you look for these features than QFace is probably the wrong choice.
Limitations
===========
-As every code generation tool QFace is also limited to how much information you place inside your interface files. So there might be areas where code generation just do not make sense, than QFace will also not help.
+Like other code generation tools, QFace is limited by how much information you can place inside your interface files. In such cases code generation might not make sense and QFace will also help.
-QFace allows you to use annotation which can add meta information to the interface files. But the genertor needs to be designed to understand this meta information. Only the structure of these annotations are defined not the information they carry. Annotations might helpt to add information to an interface document to better control the code generation process.
+QFace allows you to use annotation which can add meta information to the interface files. But the generator needs to be designed to understand this meta information. Only the structure of these annotations are defined not the information they carry. Annotations might help to add information to an interface document to better control the code generation process.
diff --git a/docs/qtcpp.rst b/docs/qtcpp.rst
index b475ffd..83d7747 100644
--- a/docs/qtcpp.rst
+++ b/docs/qtcpp.rst
@@ -31,7 +31,7 @@ For example an QFace document like this
}
-The QTCPP generator will generate all CPP code including the plugin code and project files. Additional it will generate an empty simulation stub.
+The QTCPP generator will generate all CPP code including the plugin code and project files. Additionally it will generate an empty simulation stub.
In QML you would now be able to write the following code.
@@ -66,7 +66,7 @@ Code Generation
===============
-For each module the generator creates the qmake project files, the plugin code to register the types. A module singleton which contains the enums and factory functions for creating the structures. The structure has no signals and the values are copied over.
+For each module the generator creates the qmake project files, the plugin code to register the types, a module singleton which contains the enums and factory functions for creating the structures. The structure has only properties and no operations or signals.
.. code-block:: yaml
@@ -86,7 +86,7 @@ For each module the generator creates the qmake project files, the plugin code t
- private/struct.h
- private/struct.cpp
-An base implementation of the interface is generated in the private folder. A stub implementation derived form the abstract interface is generated and registered with the plugin.
+A base implementation of the interface is generated in the private folder. A stub implementation derived form the abstract interface is generated and registered with the plugin.
Each structure is generates as a Q_GADGET which behaves similar as a JS object on the QML side. The interface is by default registered as a normal QML type and contains the properties and methods as also signals as defined in the interface files.
@@ -117,7 +117,7 @@ To extend the implementation the user needs to modify the interface implementati
In the interface document you are able to overwrite all setters and getters as also the operation methods. This is normally the only file you want to modify.
-Besides the interface files also the plugin and project files are preserved, as it is expected that these files might be required to change. This may change in the future.
+Besides the interface files also the plugin and project files are marked to be preserved. The preserve-marker means the user can edit these files and the generator will never overwrite existing files. To trigger a re-generation the user needs to remove the files first and run the generator again.
diff --git a/docs/qtqml.rst b/docs/qtqml.rst
index e7e1ae1..2c2720d 100644
--- a/docs/qtqml.rst
+++ b/docs/qtqml.rst
@@ -2,7 +2,7 @@
Qt QML Code Generator
=====================
-The Qt QML Code generator creates a pure QML implementation of the provided QFace interface files. From the QML perspective it is API compatible. This means an HMI written in QML can be run against plugins generated from the QtCPP code genrator and QtQML code generator.
+The Qt QML Code generator creates a pure QML implementation of the provided QFace interface files. From the QML perspective it is API compatible. This means an HMI written in QML can be run against plugins generated from the QtCPP code generator and QtQML code generator.
This allows developers to start early with an QML only implementation and later switch to an QtCPP based implementation, without changing the HMI code.
@@ -10,9 +10,9 @@ This allows developers to start early with an QML only implementation and later
As the HMI is limited to the API there might still be differences in behavior of the two implementations. This is in the nature of APIs and might lead to different result.
-For each module the genrator creates a module JS file, which contains the enums and factory methods for the structure. A structure is in the pure QML implementation just a JS object with correct attributes set.
+For each module the generator creates a module JS file, which contains the enums and factory methods for the structure. A structure is in the pure QML implementation just a JS object with correct attributes set.
-The interfaces are generates as QtObject types and contain the typical properties, operations and signals.
+The interfaces are generated as QtObject types and contain the typical properties, operations and signals.
.. rubric:: Code Generation
diff --git a/docs/usage.rst b/docs/usage.rst
index 8cc059f..af0e06b 100644
--- a/docs/usage.rst
+++ b/docs/usage.rst
@@ -18,7 +18,7 @@ Invocation
Direct Invocation
-----------------
-You can call the generator directly by using the provided script. All generator should at minimum expect a series of inputs and one output path. This is normally recommended for production.
+You can call the generator directly by using the provided script. All generators should at minimum expect a series of inputs and one output path. This is normally recommended for production.
.. code-block:: sh
@@ -70,7 +70,7 @@ And then call the client with:
Code Generation Principle
=========================
-The code generation is driven by a small script which iterates over the domain model and writes files using a template language (see http://jinja.pocoo.org) and espcially the template designer documentation (http://jinja.pocoo.org/docs/dev/templates/).
+The code generation is driven by a small script which iterates over the domain model and writes files using the Python Jinja template language. Refer to http://jinja.pocoo.org and particularly the template designer documentation at http://jinja.pocoo.org/docs/dev/templates/.
.. code-block:: python
@@ -99,4 +99,4 @@ This script reads the input directory returns a system object form the domain mo
{% endfor -%}
{% endfor %}
-The template iterates over the domain objects and generates text which is written into a file. The file name is also adjustable using the same template language.
+The template iterates over the domain objects and generates text which is written into a file. Using the generator write method ``generator.write(path, template, context)`` the output file path can also be specified using the template syntax .
diff --git a/qface/__about__.py b/qface/__about__.py
index 6082fa1..71bd751 100644
--- a/qface/__about__.py
+++ b/qface/__about__.py
@@ -9,6 +9,6 @@ except NameError:
__title__ = "qface"
__summary__ = "A generator framework based on a common modern IDL"
__uri__ = "https://pelagicore.github.io/qface/"
-__version__ = "1.1b1"
+__version__ = "1.1b2"
__author__ = "JRyannel"
__author_email__ = "qface-generator@googlegroups.com"