Propoerty access

When a member function returns a property that is directly known, the function name should be directly similar to the propoerty name. Example: SomeObject::isNull() .

If a member function needs some processing before returning the requested value, it should be prefixed get. For example, we suppose that getting available tables in a database needs to query the database, the function should be named like SomeObject::getAvailableTables(T db).

Return value

When a function fails, it should be possible to get the reason why it failed. This is done by using the Mdt::Error class.

Functionnal classes should store a Mdt::Error as member and provide lastError() function. Their member functions should follow these rules:

If the function can fail, but returns no data, it should return a bool and store the error in lastError.
If the function can fail, and returns data, it should return a mdtExpected. For coherence reason, the error should also be stored in lastError.
If the function can fail, and it is static, it should return a Mdt::Expected.

Value classes should not have functions that can fail, because they do not, for example, read files. If it occurs that function can fail, they should follow these rules:

If the function can fail, it should return a Mdt::Expected.

Error handling

Dialogs

A dialog is a top level widget that is displayed to the user. When a error occurs, the dialog should also display it to the user.

If a public function can fail (for example setting a file), it should display the error to the user and return false, so the caller knows that something failed and he adapt his flow.

Note: If something could fail, the dialog should inform the user, and should not be acceptable.

Ui files when using QtDesigner

One of the possible way to use headers generated by uic, is to inherit from the base class and from the class generated by uic. This option requires that ui_*.h is included in the header file of the class. Because this header file is generated during compilation, it will be somwhere in the build tree. For this library, this issue has to be solved, and is by setting correct CMake options. But, the problem will then happen again to the user, which has no access to this ui_*h file.

To solve this issue, the Ui class should be forward declared in the header, used as member of the class, using a unique_ptr. The ui_*h file can also be included in the *.cpp file. See Mdt::ItemEditor::StandardWindow to see a example of this usage.

Translations

About using tr()

When a class is a subclass of QObject, simply using tr() works fine.

For a class that is not a subclass of QObject, Qt recommends using QCoreApplication::translate() and provide the class name as context, so that Qt Linguist can display it the proper way to the translator. Previously, many classes in Mdt libraries have added a tr() static member function, that simply called QObject::tr(). This is bad, because Qt Linguist also displayed all strings as QObject context. The recommanded solution is to use Q_DECLARE_TR_FUNCTIONS() provided in QCoreApplication For example, in MyClass.h:

#include <QCoreApplication>
class MyClass
{
  Q_DECLARE_TR_FUNCTIONS(MyClass)
 public:
  MyClass();
};

Note that Qt Linguist trows error messages when a class uses tr() and it does not provide the Q_OBJECT macro, despite the fact that translation file are generated and works.

Library exports

For some platforms, classes and functions that are used outside a shared library must be exported explicitly in the header.

Mdt uses CMake to generate the MDT_LIBNAME_EXPORT macro. This macro is defined in MdtLibnameExport.h, which is not available in the source tree, but generated during compilation. When using mdt_add_library() to create a Mdt library, the path to the directory where Export.h is located will be added.

Example of a class that must be accessible outside the ItemModel shared library:

#include "MdtItemModelExport.h"
class MDT_ITEMMODEL_EXPORT MyClass
{
};