diff options
author | Juergen Bocklage-Ryannel <juergen.bocklage-ryannel@pelagicore.com> | 2017-02-03 13:13:46 +0100 |
---|---|---|
committer | Juergen Bocklage-Ryannel <juergen.bocklage-ryannel@pelagicore.com> | 2017-02-03 13:13:46 +0100 |
commit | 108488b41beffd2f355cdf3b24e45d63aed093d9 (patch) | |
tree | 983b2813723a4ce1f1744a16771a1ab70698853a | |
parent | 6dd57dc8ebf1db3f143350c46890a2a8bff3308c (diff) | |
download | qtivi-qface-108488b41beffd2f355cdf3b24e45d63aed093d9.tar.gz |
Updated documentation to replace event with signal.
-rw-r--r-- | README.md | 4 | ||||
-rw-r--r-- | USAGE.md | 2 | ||||
-rw-r--r-- | docs/grammar.rst | 6 | ||||
-rw-r--r-- | docs/qtcpp.rst | 10 |
4 files changed, 11 insertions, 11 deletions
@@ -50,7 +50,7 @@ on the other side interface Echo { readonly Message lastMessage; void echo(Message message); - event void callMe(); + signal callMe(); }; struct Message { @@ -76,6 +76,6 @@ for module in system: ctx = { 'interface': interface } # use header.h template with ctx to write to a file generator.write('{{interface|lower}}.h', 'header.h', ctx) -``` +``` Depending on the used generator it reads the input file and runs it through the generator. The output files are written relative to the given output directory. The input can be either a file or a folder. @@ -34,7 +34,7 @@ The IDL grammar is described in the grammar file (see qface/parser/idl/T.g4) interface <identifier> { (readonly) <type> <property>; <type> <operation>([type name]); - event <type> <operation>([type name]); + signal <signal>([type name]); list<type> <property>; model<type> <property>; } diff --git a/docs/grammar.rst b/docs/grammar.rst index c858e77..c5acd91 100644 --- a/docs/grammar.rst +++ b/docs/grammar.rst @@ -12,7 +12,7 @@ QFace (Qt interface language) is an IDL to define an interface. In general it is interface <Identifier> { <type> <identifier> <type> <operation>(<parameter>*) - event <type> <event>(<parameter>*) + signal <signal>(<parameter>*) } struct <Identifier> { @@ -40,7 +40,7 @@ Types Types are either local and can be references simply by its name, or they are from external module in this case they need to be referenced with the fully qualified name (``module + '.' + name``). A type can be an interface, struct, enum or flag. -A module consist of either one or more interfaces, structs and enums/flags. They can come in any number or combination. The interface is the only type which can contain operations and events. The struct is merely a container to transport structured data. An enum/flag allows the user to encode information used inside the struct or interface as datatype. +A module consist of either one or more interfaces, structs and enums/flags. They can come in any number or combination. The interface is the only type which can contain operations and signals. The struct is merely a container to transport structured data. An enum/flag allows the user to encode information used inside the struct or interface as datatype. The QFace does not allow to extend interfaces. It is by design kept simple. @@ -108,7 +108,7 @@ Below is an example of a QFace file. Tags / Annotations ================== -Tags allows an interface author to extend the existing grammar with additional meta information, called tags, aka annotations. One or several annotations can stand in from of a module, interface, struct or enum. They are also allowed before an operation, property or event. Everywhere where a documentation comment is allowed you can also add annotations. +Tags allows an interface author to extend the existing grammar with additional meta information, called tags, aka annotations. One or several annotations can stand in from of a module, interface, struct or enum. They are also allowed before an operation, property or signal. Everywhere where a documentation comment is allowed you can also add annotations. An annotation looks like this:: diff --git a/docs/qtcpp.rst b/docs/qtcpp.rst index 2eb3ede..5178eac 100644 --- a/docs/qtcpp.rst +++ b/docs/qtcpp.rst @@ -21,7 +21,7 @@ For example an QFace document like this Status status; void increaseTemperature(real step); void decreaseTemperature(real step); - event void error(string message); + signal error(string message); } enum Status { @@ -79,7 +79,7 @@ For each module the generator creates the qmake project files, the plugin code t - private/module.cpp - for each interface: - private/abstractinterface.h - - private/abstractinterface.cpp + - private/abstractinterface.cpp - interface.h - preserve - interface.cpp - preserve - for each struct: @@ -98,11 +98,11 @@ Design Decisions Writable properties on service objects are a cause of errors and confusion. It is very easy in the HMI stack to overwrite a binding property which writes to a service. It is better to offer a dedicated operation which does some work and triggers an operation update. * All models generated are read only from QML - + The data for a model is often stored inside another system (SQL DB, Remote, File System) and only a small subset of the data is actually in memory. Filtering, sorting or modifying the model data should be explicitly done using operations if supported by the user interface. * Data structures are exported as gadgets - + A Q_GADGET allows us to define a data structure and modify its contents. A gadget does not support signals, which means others are not notified about changes. This is the same behavior as for JS objects. Gadgets are copied from C++ to QML so there is no issue with memory management. QML has no means to create a gadget class, for this the module object contains a factory method for each structure. * Enums are collected into one module object @@ -122,4 +122,4 @@ Besides the interface files also the plugin and project files are preserved, as - + |