I am attempting to use doxygen to comment my Qt5 classes, in particular the Q_PROPERTY macro in the same manner as the Qt5 documentation. This has the property commented, with accessors and notifier if needed. Now I can produce that using Nathan Osman's and Maxim Paperno's hints from How to doxygen comment Qt properties? however although they show the accessors and notifiers correctly, in Qt5 there is also a link back from the method documentation to the property, i.e. the documentation has a link from text() and setText() to the properties documentation, rather than having their own, which I cannot reproduce.
The doxygen config for these are:
"ALIASES += accessor=\\par Access functions:^^"
"ALIASES += notifier=\\par Notifier signal:^^"
The .h file has the following as property and public method declaration. The two % characters block a link from the property accessor documentation to the method documentation the same way as in Qt. Obviously I have left out a lot of unnecessary stuff from the code..
/*!
\property MyClass::text
\brief This property holds the classes's text.
By default, this property contains an empty string.
#accessor %text(void), %setText()
*/
Q_PROPERTY(QString text READ text WRITE setText)
QString text() const;
void setText(const QString& text);
private:
QString m_text;
The cpp code has the following definition
QString MyClass::text() const
{
return m_text;
}
void MyClass::setText(const QString& text)
{
m_text = text;
}
Is there any way to reproduce this with doxygen?
Right thanks #albert for that. I did mean accessor not accessors a slight bit of finger trouble. Doxygen version is 1.8.17.
I am using doxygen to document some of my custom classes, however in Qt 5.15.0, and 4.8 at least, the documentation as in doxygen consists of lists of properties/methods etc. followed by more detailed documentation.
If there is a property with accessors, then the method in the list section links to the property details, rather than a method detail. However I haven't found a way of making that link using doxygen. The method in the list section has no link.
There is also a problem with propertied methods with the same property name and accessor name not showing documentation for the method, if you write extra for method. I tried doing it that way earlier.
Related
A simple question regarding the new signal/slot syntax in Qt5:
Are there still benefits for a Q_OBJECT-derived class to have public slots: sections declared?
Note: With the new syntax you're able to connect a signal to any public function of a class or directly implement a C++11 lambda (which can also call some member functions itself).
Qt's new signal/slot syntax
While the answers by vahancho and TheDarkKnight are valid: slots is not required for connections, but it makes the intent clearer and allows introspection. I think I should list some use cases where you do need slots.
First please note that you can use slots, Q_SLOTS, Q_SLOT or Q_INVOKABLE to make a function known to the meta object (introspection) system. Q_INVOKABLE has the advantage that it can be used on constructors.
And here are the use cases in no particular order:
Make your code works with Qt 4. Even if Qt 4 is not maintained I think some big company are still using it and it is fairly easy to make a library works with Qt 5 and Qt 4.
Make the function available in QML (and Qt Quick)
Make the function available in javascript (Qt Script, Qt WebEngine, etc.)
Make the function callable with QMetaObject::invokeMethod(). An overload that accepts functors will be available in Qt 5.10.
Make use of QMetaObject::connectSlotsByName(). Note that this function should not be used as it can be affected by object name collisions, but it is still the way the Qt widget designer connects the slots it creates.
Make your class instantiatable with QMetaObject::newInstance().
And every other use case that requires run-time introspection
you're able to connect a signal to any public function of a class or directly implement a C++11 lambda
Whilst this was made available in Qt 5, which allows for compile-time verification of the slot, as opposed to when using the SIGNAL and SLOT macros, it is no longer a requirement to declare a function as a slot to connect to it.
However, for clarity I still do, as it makes the intention of a class clearer for usage, when others come to using the class.
For example:
class Foo : public QObject
{
public:
Foo();
public slots:
void AddData();
private:
void CalculateStuff();
};
Just by looking at the class, we can assume that the function AddData is designed to be called via a signal; perhaps it executes on a separate thread.
public slots: etc. declarations still needed for moc introspection if you are going to use the "old" connection style. With the new syntax this declarations do not make any sense, because, as you also noticed, "slots" are called directly by function pointers. "Slots" may even be a non class member functions as well.
However, you still need to declare your signals under signals: section of your class declaration.
They're still needed for Qml, so that you can connect to C++ slots. However, if you want to call a C++ QObject member function, you can just declare it as Q_INVOKABLE. You don't need to make it a slot. Although using slots: might be more readable compared to using Q_INVOKABLE. Up to you.
They're also needed if you want Designer to see them. Designer has a "signal/slot" editor, and it will not list functions that are not in the slots: section. However, Designer still uses the old string-based syntax for signals and slots, so I wouldn't recommend using its signal/slot editor.
I have got a QQuickView which has loaded a qml file like the following.
Rectangle { width: 100; height: 100 }
Then I am retrieving the root object via QObject *root = view->rootObject().
Now I want to get the class name from this object.
The following code results into "QQuickRectangle"
root->metaObject()->className()
But what I want is "Rectangle" just like the typename in the qml file.
Any idea?
Edit: I want to build a treeview with the object hirarchie of a qml file like QtCreator.
There is a pattern there, for qml types implemented in C++ the name would be QQuickSomething, for qml types implemented in qml the name would be Something_QMLTYPE_X_MAYBEMORESTUFF(objAddress).
So you can do some basic string editing depending on the result you get to isolate the actual type name:
QString name = QString(root->metaObject()->className());
if (name.contains("QQuick")) name.remove("QQuick");
else if (name.contains("QMLTYPE")) name.remove(QRegExp("_QMLTYPE_[0-9]*.*"));
// else it might be just a QObject or your on custom type you should handle
Edit: I want to build a treeview with the object hirarchie of a qml
file like QtCreator.
Unless you are willing to dig into and use private APIs, it would likely be easier and also more useful to have your own custom model to drive both a view and the actual object tree. Also, QML is quite easy to parse, I'd personally buckle down and write a parses faster than it would take me to get into the existing one, especially if all that is needed is an object tree outline, but YMMV.
There is "better" information kept on this (QQmlType & QQmlMetaType), but it is not accessible through any public API that I can think of.
Can you explain what you would like to do with it? Maybe there's an alternative.
QtQuick doesn't provide some special metadata for QML items. It looks that QtQuick uses item types internally only while parsing the source.
The known workaround is objectName:
Rectangle {
objectName: "Rectangle"
}
and so:
QString className = item->objectName();
What is an optimal and an appropriate way to save the state of a Qt GUI so I get the same state I had back when I closed the application ?
By state I mean : current indexes (for combo box ...), color palette, widgets positions... right before closing the application
You can use the QSettings class.
Simple use of QSettings class (code inspired from Qt's documentation):
In the main-window of your application code member functions that saves and restore the settings:
void MainWindow::writeSettings()
{
QSettings settings("reaffer Soft", "reafferApp");
settings.beginGroup("MainWindow");
settings.setValue("size", size());
settings.setValue("pos", pos());
settings.endGroup();
}
void MainWindow::readSettings()
{
QSettings settings("reaffer Soft", "reafferApp");
settings.beginGroup("MainWindow");
resize(settings.value("size", QSize(400, 400)).toSize());
move(settings.value("pos", QPoint(200, 200)).toPoint());
settings.endGroup();
}
Call those 2 functions from the MainWindow constructor and from the closeEvent override, like this:
MainWindow::MainWindow()
{
// code from constructor
//...
readSettings();
}
void MainWindow::closeEvent(QCloseEvent *event)
{
//optional check if the user really want to quit
// and/or if the user want to save settings
writeSettings();
event->accept();
}
The direct answer requires specific elaborated design for your code and not really a short Qt question or even the question specific to Qt. That is about C++ which is not the VM-based language that assists with serializing the state of program code to data. Having all objects serializable we can then attempt to apply certain C++/Qt classes/techniques.
This task is much easier to accomplish with languages like Java, though. And with C++/Qt you have to routinely make serialize-able / serialize / restore everything that is running in your code and still no guarantee that works as long as the context is not fully captured. This task is not easy for sure and makes sense only in specific application.
The most you can get directly from Qt is to save/restore QMainWindow and other independent widgets geometry (position/size):
saveGeometry
restoreGeometry
... and that solution is still somewhat incomplete or you may/not use QSettings for the storage.
I use QSettings for this. With routines similar to Zlatomir's.
For each window I have in the project I use a different section in QSettings and have readSettings() and writeSettings() in the source for each window.
Anything on the form that I want to persist I have to explicitly save and recall. In the case of a QComboBox it would be something like:
QSettings settings("Organisation", "MySoftware");
settings.beginGroup("WindowNumberTwo");
settings.setValue("ComboIndex", combobox->currentIndex());
// save more values here
// ...
settings.endGroup();
I don't know of a built in way to persist your window states - it has to be don't value by value.
I am learning GUI coding with Qt and hope to clear up some confusion on my part. When I create a dialog with Qt Creator it creates code for me like this...
#ifndef LISTDIALOG_H
#define LISTDIALOG_H
#include <QDialog>
#include "ui_listdialog.h" //Q1:Why was this auto paced in cpp file instead of h file?
//Q2: This is what I'm really confused about.
//Is Ui namespace wrapping ui_listdialog class or the ListDialog class?
namespace Ui {
class ListDialog;
}
class ListDialog : public QDialog
{
Q_OBJECT
public:
explicit ListDialog(QWidget *parent = 0); //Q3: Why is this constructor explicit?
~ListDialog();
//CUSTOM FUNCTIONALITY NOT ADDED BY CREATOR (IGNORE FOR MY POST)
private slots:
void addItem();
void editItem();
void deleteItem();
//END CUSTOM FUNCTIONALITY
private:
Ui::ListDialog *ui; //Placed on heap instead of stack.
};
#endif // LISTDIALOG_H
There are things in the above code that differ from my 3 Qt books (all 3 out of date and ignore Creator).
My main confusion comes from Q2. Is "Ui" wrapping "ui_listdialog.h" or the class I have posted here ( class ListDialog )? The syntax seems to imply to me that it is wrapping the latter but I feel it must be actually wrapping the ui_listdialog.h class instead. Very confused about this. Can someone explain this clearly?
I also don't understand why the constructor was made explicit by Creator. I have not seen that in any of the 3 books.
Q1. The #include is placed in the .cpp to avoid too many dependencies in the header file. This shortens compilation time, because if you change the dialog, the only thing you have to recompile is the .cpp and not everything that includes your header file. In general, if a forward declaration of a class is enough (i.e. you only have a pointer or a reference to it in your class), then it's better not to #include the class's definition.
Q2. Ui is a namespace that contains a different class called ListDialog. You can open the header file and see the definition of this other class. A bit confusing until you get used to it.
Q3. It's a good habit to use the explicit keyword with constructors that take a single parameter. Otherwise the constructor can also be used as an automatic conversion operator, and this can cause problems if you're not aware of it. For example, if you have a function that takes a ListDialog parameter, and you pass a QWidget * parameter, it may call the constructor when in fact you want the compiler to shout (invalid parameter).
The ui_listdialog.h contains implementation to generate your user interface based on Qt Designer. It isn't necessary when declaring the class -- that's why the file was #included in the .cpp (Q1). Without the ui_listdialog.h in the header, the class declaration is necessary (Q2).
As for Q3, it's probably there to make you use the constructor syntax. Else, you could write misleading statements like
ListDialog dialog = parentDialog ;
I'm looking for a way to preserve the size of windows in a Qt app.
I've seen that there is the possibility of using the following method for every widget:
saveGeometry()
But really, I don't find this a satisfactioning method. Is there something like setAutosaveGeometry(True)?
I'm especially looking for a way to store the widths of table columns.
The QHeaderView class also has two methods for saving and restoring it's state to and from a QByteArray: saveState()and restoreState()
A table view's headers are accessible via the horizontalHeader() and verticalHeader() methods.
saveGeometry returns a QByteArray value, you need to store it somewhere.
Example:
void MainWindow::closeEvent(QCloseEvent *event){
QSettings settings;
settings.setValue("geometry", saveGeometry());
}
For reading the geometry call the restoreGeometry function:
MainWindow::MainWindow(QWidget *parent):QMainWindow(parent) {
[...]
QSettings settings;
restoreGeometry(settings.value("geometry").toByteArray());
[...]
}
To learn more about window geometry please read the documentation
See the Qt documentation on Restoring a Window's Geometry.