Is there a Qt-specific way to implement getters and setters? Perhaps there are Qt macros or something similar.
Q_PROPERTY
From the documentation ( https://qt-project.org/doc/qt-4.8/properties.html ):
Qt provides a sophisticated property system similar to the ones supplied by some compiler vendors. However, as a compiler- and platform-independent library, Qt does not rely on non-standard compiler features like __property or [property]. The Qt solution works with any standard C++ compiler on every platform Qt supports. It is based on the Meta-Object System that also provides inter-object communication via signals and slots.
standard setter and getter looks like this:
void YourClass::setSomeValue(const type &newValue) {
if (newValue!=someValue) {
someValue = newValue;
emit someValueChanged(someValue);
// some optional invocations to update sizeHint or schedule widget redrawing ... :
update();
updateGeometry();
}
}
type YourClass::someValue() const {
return someValue;
}
if you are looking for something like #synthesize in Objcetive C there is no such thing in Qt, but you can define your own macro (I do something like that sometimes).
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.
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 have a simple need : I have defined a C++ class
class MyClass: public QDeclarativeItem
{
Q_OBJECT
public:
MyClass(QDeclarativeItem * parent=0);
...
private:
QList<QString> mList
}
And of course, I've registered it : qmlRegisterType<MyClass>(...)
I want to access in the QML code to my QList<QString> mList. How can I do it?
It annoys me as it looks like a simple problem, but I can't find anything about this. (I can create a Q_INVOKABLE slot, but I can't read the results, etc...)
Edit : QML supported Data Types
I don't think that QList is a supported data type for Qt's QML binding. I've had similar problems interfacing between C++ and JavaScript using the QtWebkit Bridge.
If possible, try using a QVariantList instead of a QList. Although this is technically a typedef for QList<QVariant> I think it should work.
If you need a custom type in your list (not just strings or other basic types) there's QDeclarativeListProperty for that case.
But it's more complicated, see http://doc.qt.nokia.com/4.7/declarative-tutorials-extending-chapter5-listproperties.html
I am relatively new to programming with Qt and had a question. Short version:
How do I inherit signals defined in superclasses?
I am trying to subclass someone else's nicely made QTWidgets to change some of the default behavior:
//Plot3D is a QWidget that defines a signal "rotationChanged"
class matLinePlot : public QObject, public Plot3D {
Q_OBJECT;
//etc...
public:
//etc...
//Catch Plot3D's signal "rotationChanged" and do some magic with it:
void initPlot(){
QObject::connect(this, SIGNAL(rotationChanged( double , double , double )),
this, SLOT(myRotationChanged(double, double, double)));
}
};
The problem is in the QObject::connect line. What I would like to do is connect the rotationChanged SIGNAL (from qwt3D_plot.h) to a local function/SLOT - "myRotationChanged". However whenever I do this, at run time I get:
Object::connect: No such signal matLinePlot::rotationChanged(double, double, double)
in C:...\matrixVisualization.h. Of course, I know that rotationChanged isn't in matrixVisualization.h - it's in qwt_plot3D.h, but I thought that since I inherit from Plot3D everything should be fine. But, now that I think about it, since SIGNAL and SLOT are macros, I assume MOC doesn't know/care about inheritance.
Which leads me to my question - since MOC and SIGNALS / SLOTS don't seem to know about inheritance etc: how can I subclass a widget defined somewhere else and get access to the widget's signals?
I have a lot of examples of how to use encapsulation to accomplish something like this, but I'm afraid I don't understand how to do this with inheritance.
Sorry if this is a ridiculous question - I feel like I'm missing something obvious.
I guess the problem is the multiple inheritance:
class matLinePlot : public QObject, public Plot3D
...
I assume that Plot3D is a subclass of QObject? In this case, you should do
class matLinePlot : public Plot3D
...
instead.
SIGNAL(x) and SLOT(x) are macros that generate string literals. At runtime, slots and signals are matched up using string compares of those generated literals.
(I would have added a comment to mdec's comment, but I don't have enough rep)
I believe that will work if the Plot3D::rotationChanged signal is public or protected. Are you sure the signal is not private?
Edit:
Although I could not find a specific reference, I'll have to conclude that signals are always public. At least a test I did here seemed to indicate that I could connect to a signal even if it was declared in the private section of a class.
I also verified that a signal declared in QObject could be connected using a subclass of QObject in the connect statement so signals are definitely inheritable. As I see in other answers and comments here, the issue must be elsewhere.
Incorrect -> see comments.
I'm using Qtopia at Uni and I believe I recall someone saying something about spacing in the SIGNAL and SLOT parameters for connect.
Try using
QObject::connect(this, SIGNAL(rotationChanged(double,double,double)),
this, SLOT(myRotationChanged(double,double,double)));
I know it doesn't seem intuitive, as C++ isn't sensitive to whitespace, however I believe it has something to do with some of the magic that Qtopia/QT uses when connecting signals and slots. This may only apply to Qtopia, or I may have heard wrong, but give it a try. Additionally are the signals public or protected and have you included the appropriate header files?