Q_Properties in a Qt program
-
Something strange!
I even shortened the code more, to this state:
#ifndef ICONEDITOR_H #define ICONEDITOR_H #include <QColor> #include <QImage> #include <QWidget> class IconEditor : public QWidget { Q_OBJECT public: IconEditor(QWidget *parent = 0); QColor penColor() const { return curColor; } void setIconImage(const QImage &newImage); QSize sizeHint() const; ~IconEditor(); protected: void mousePressEvent(QMouseEvent *event); void mouseMoveEvent(QMouseEvent *event); void paintEvent(QPaintEvent *event); private: void setImagePixel(const QPoint &pos, bool opaque); QRect pixelRect(int i, int j) const; QColor curColor; QImage image; int zoom; }; #endif // ICONEDITOR_HThese are all the code needs to run. But the odd thing here is that why the author expanded the code to the one written in the first post of this thread! (from 35 lines of code to 43 only in the header!)
I don't understand, do you? -
Something strange!
I even shortened the code more, to this state:
#ifndef ICONEDITOR_H #define ICONEDITOR_H #include <QColor> #include <QImage> #include <QWidget> class IconEditor : public QWidget { Q_OBJECT public: IconEditor(QWidget *parent = 0); QColor penColor() const { return curColor; } void setIconImage(const QImage &newImage); QSize sizeHint() const; ~IconEditor(); protected: void mousePressEvent(QMouseEvent *event); void mouseMoveEvent(QMouseEvent *event); void paintEvent(QPaintEvent *event); private: void setImagePixel(const QPoint &pos, bool opaque); QRect pixelRect(int i, int j) const; QColor curColor; QImage image; int zoom; }; #endif // ICONEDITOR_HThese are all the code needs to run. But the odd thing here is that why the author expanded the code to the one written in the first post of this thread! (from 35 lines of code to 43 only in the header!)
I don't understand, do you?Presumably because author intended this class to be more reusable, e.g. like widgets that are part of Qt. Built-in widgets have getters and setters for all their properties, as well as Q_PROPERTY declarations, to not limit you in different usage scenarios. If you are developing widget to be used in specific place of specific project, you can cut off a lot of unneeded stuff and make it simpler.
-
Thank you. I even made it shorter. Not a good policy to me if the author has intended it for a reader who is "learning" new things to be overwhelmed by useless methods wasting time while they don't have any real usage at the given example. If he wanted he could use them all in a more appropriate example.
-
Thank you. I even made it shorter. Not a good policy to me if the author has intended it for a reader who is "learning" new things to be overwhelmed by useless methods wasting time while they don't have any real usage at the given example. If he wanted he could use them all in a more appropriate example.
@tomy
Actually, in the very next chapter he uses those properties to integrate as plugin into Designer
http://www.informit.com/articles/article.aspx?p=1405227&seqNum=3
So he had a plan with it. -
Hi,
So I will deal with those properties on that chapter with the experience I gained from here. Thanks.One other question. In prior apps we would use setLayout for showing the output. Here I don't see that tool. What part of the code does this duty please? That is, it brings the window up for the rest of the program.
-
Hi,
So I will deal with those properties on that chapter with the experience I gained from here. Thanks.One other question. In prior apps we would use setLayout for showing the output. Here I don't see that tool. What part of the code does this duty please? That is, it brings the window up for the rest of the program.
@tomy said in Q_Properties in a Qt program:
In prior apps we would use setLayout for showing the output
Nope, setLayout is used to, unsurprisingly, lay out multiple widgets. This example is a single widget that takes care of painting itself so no need for layouts
"La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
~Napoleon BonaparteOn a crusade to banish setIndexWidget() from the holy land of Qt
-
@tomy said in Q_Properties in a Qt program:
In prior apps we would use setLayout for showing the output
Nope, setLayout is used to, unsurprisingly, lay out multiple widgets. This example is a single widget that takes care of painting itself so no need for layouts
@VRonin
We have a window that in main.cpp using the instruction below we set its title to "Icon Editor":
iconEditor.setWindowTitle(QObject::tr("Icon Editor"));
Then that window will be used for painting using the paintEvent function.
I mean, how will that window be up/shown? Using what function/instructions? -
Hello,
I still have some issues on this example:
main.cpp:
#include <QApplication> #include "iconeditor.h" int main(int argc, char* argv[]) { QApplication app(argc, argv); IconEditor iconEditor; iconEditor.setWindowTitle(QObject::tr("Icon Editor")); iconEditor.setIconImage(QImage(":/images/mouse.png")); iconEditor.show(); return app.exec(); }iconeditor.h:
#ifndef ICONEDITOR_H #define ICONEDITOR_H #include <QColor> #include <QImage> #include <QWidget> class IconEditor : public QWidget { Q_OBJECT Q_PROPERTY(QColor penColor READ penColor WRITE setPenColor) Q_PROPERTY(QImage iconImage READ iconImage WRITE setIconImage) Q_PROPERTY(int zoomFactor READ zoomFactor WRITE setZoomFactor) public: IconEditor(QWidget *parent = 0); QColor penColor() const { return curColor; } QImage iconImage() const { return image; } int zoomFactor() const { return zoom; } void setPenColor(const QColor &newColor); void setIconImage(const QImage &newImage); void setZoomFactor(int newZoom); QSize sizeHint() const; ~IconEditor(); protected: void mousePressEvent(QMouseEvent *event); void mouseMoveEvent(QMouseEvent *event); void paintEvent(QPaintEvent *event); private: void setImagePixel(const QPoint &pos, bool opaque); QRect pixelRect(int i, int j) const; QColor curColor; QImage image; int zoom; }; #endif // ICONEDITOR_Hiconeditor.cpp:
#include <QtWidgets> #include "iconeditor.h" IconEditor::IconEditor(QWidget *parent) : QWidget(parent) { setAttribute(Qt::WA_StaticContents); setSizePolicy(QSizePolicy::Minimum, QSizePolicy::Minimum); curColor = Qt::blue; zoom = 8; image = QImage(16, 16, QImage::Format_ARGB32); image.fill(qRgba(0, 0, 0, 0)); } //******************************************************* void IconEditor::setPenColor(const QColor& newColor) { curColor = newColor; } //************************************************** void IconEditor::setZoomFactor(int newZoom) { if (newZoom < 1) newZoom = 1; if (newZoom != zoom) { zoom = newZoom; update(); updateGeometry(); } } //*********************************************************** void IconEditor::setIconImage(const QImage &newImage) { if (newImage != image) { image = newImage.convertToFormat(QImage::Format_ARGB32); update(); updateGeometry(); } } //******************************************** QSize IconEditor::sizeHint() const { QSize size = zoom * image.size(); if (zoom >= 3) size += QSize(1, 1); return size; } //******************************************* void IconEditor::paintEvent(QPaintEvent *event) { QPainter painter(this); qDebug() << image.height() << ' ' << image.width() <<endl; if(zoom >= 3) { painter.setPen(palette().foreground().color()); for(int i = 0; i< image.width(); ++i) painter.drawLine(zoom * i, 0, zoom *i, zoom * image.height()); for(int j = 0; j<image.height(); ++j) painter.drawLine(0, zoom * j, zoom * image.width(), zoom * j); } for(int i = 0; i<image.width(); ++i) for(int j = 0; j < image.height(); ++j) { QRect rect = pixelRect(i, j); if(!event->region().intersected(rect).isEmpty()) { QColor color = QColor::fromRgba(image.pixel(i, j)); if(color.alpha() < 255) painter.fillRect(rect, Qt::white); painter.fillRect(rect, color); } } } //************************************************ QRect IconEditor::pixelRect(int i, int j) const { if( zoom >= 3) return QRect(zoom * i + 1, zoom * j + 1, zoom-1, zoom-1); else return QRect(zoom * i, zoom * j, zoom , zoom); } //************************************************** void IconEditor::mousePressEvent(QMouseEvent *event) { if(event->button() == Qt::LeftButton) setImagePixel(event->pos(), true); else if(event->button() == Qt::RightButton) setImagePixel(event->pos(), false); } //************************************************ void IconEditor::mouseMoveEvent(QMouseEvent *event) { if(event->buttons() & Qt::LeftButton) setImagePixel(event->pos(), true); else if(event->buttons() & Qt::RightButton) setImagePixel(event->pos(), false); } //********************************************************* void IconEditor::setImagePixel(const QPoint &pos, bool opaque) { int i = pos.x() / zoom; int j = pos.y() / zoom; if(image.rect().contains(i, j)) { if(opaque) image.setPixel(i, j, penColor().rgba()); else image.setPixel(i, j, qRgba(0 , 0, 0, 0)); update(pixelRect(i, j)); } } //*************************************************** IconEditor::~IconEditor() { }The functions below are called only by those three properties:
QColor penColor() const { return curColor; } int zoomFactor() const { return zoom; } void setPenColor(const QColor &newColor); void setIconImage(const QImage &newImage); void setZoomFactor(int newZoom);But what if we don't use the properties? I meant, whether I use the properties or make them comments, the program works well in both cases. So the question is how or by what instructions/statements are those functions called when we make the properties comments (/* */), please?
@tomy said in Q_Properties in a Qt program:
how will that window be up/shown?
@tomy said in Q_Properties in a Qt program:
iconEditor.show();Qt is more intuitive than you'd think
-
On the method
void IconEditor::paintEvent(QPaintEvent *event), I think:1- QPainter painter(this): Here this is a pointer to a QPaintDevice which is here the widget we are working on.
2- if(!event->region().intersected(rect).isEmpty()): I toyed with Documentations and read about each type: event, region, intersect, and isEmpty. I know that it compares "two" rectangles for an area to be intersected and looks if such an area exists or not (it's empty). The first rectangle is our rect, what's the other one? Would you please explain this line of code a little more?
3- QColor color = QColor::fromRgba(image.pixel(i, j)): Here we first take the color of a pixel on our original icon, addressed by coordinates i and j, out, and then convert it to an Rgba format and set it to the variable color.
4- if(color.alpha() < 255) painter.fillRect(rect, Qt::white);
painter.fillRect(rect, color);
If the color obtained that way (above), "isn't" completely dark, we first set a white background, and if it "is", we won't do anything. Then we paint the rect using that color.Are all 4 correct please?
-
On the method
void IconEditor::paintEvent(QPaintEvent *event), I think:1- QPainter painter(this): Here this is a pointer to a QPaintDevice which is here the widget we are working on.
2- if(!event->region().intersected(rect).isEmpty()): I toyed with Documentations and read about each type: event, region, intersect, and isEmpty. I know that it compares "two" rectangles for an area to be intersected and looks if such an area exists or not (it's empty). The first rectangle is our rect, what's the other one? Would you please explain this line of code a little more?
3- QColor color = QColor::fromRgba(image.pixel(i, j)): Here we first take the color of a pixel on our original icon, addressed by coordinates i and j, out, and then convert it to an Rgba format and set it to the variable color.
4- if(color.alpha() < 255) painter.fillRect(rect, Qt::white);
painter.fillRect(rect, color);
If the color obtained that way (above), "isn't" completely dark, we first set a white background, and if it "is", we won't do anything. Then we paint the rect using that color.Are all 4 correct please?
- correct
- from http://doc.qt.io/qt-5/qpaintevent.html#region "Returns the region that needs to be updated." basically if the pixel (image pixel, not display pixel) you are painting is outside the area that needs to be repainted you don't bother painting it
- no, pixel already returns an rgb encoded color, you just create a QColor with it. You can actually replace it with
QColor color = image.pixelColor(i, j); - correct. The idea is that if it's completely dark it will overwrite the background anyway so might as well not bother painting the background
"La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
~Napoleon BonaparteOn a crusade to banish setIndexWidget() from the holy land of Qt
-
- correct
- from http://doc.qt.io/qt-5/qpaintevent.html#region "Returns the region that needs to be updated." basically if the pixel (image pixel, not display pixel) you are painting is outside the area that needs to be repainted you don't bother painting it
- no, pixel already returns an rgb encoded color, you just create a QColor with it. You can actually replace it with
QColor color = image.pixelColor(i, j); - correct. The idea is that if it's completely dark it will overwrite the background anyway so might as well not bother painting the background
@VRonin
Thank you.from http://doc.qt.io/qt-5/qpaintevent.html#region "Returns the region that needs to be updated." basically if the pixel (image pixel, not display pixel) you are painting is outside the area that needs to be repainted you don't bother painting it
1- I still haven't got it!
Where have we any region for updating? I don't think we have any updating on the whole program.
And, how an image pixel can be outside an area? We used the icon and created a grid according to its size.
As well as, Where do we have repainting in this application please? Everything seems to be in a rather static mode.2- Is QColor color = image.pixelColor(i, j); another style of code only or related to new version of Qt? (Because the book is somewhat outdated)
-
- Take this situation:
if you now close the notepad, the calculator does not need to repaint everything but just the region that was previously hidden so a pixel that is on the top left section is outsideevent->region()and we don't repaint it
Repainting is handled internally by Qt, it will take care of callingpaintEventevery time it needs re-painting - http://doc.qt.io/qt-5/qimage.html#pixelColor-1 : "This function was introduced in Qt 5.6."
- Take this situation:
-
OK, thank you.
What is the role ofintersected(rect).isEmpty()in that instruction, please?
That part seems to check if there even is any widget (area) for painting! It also seemingly compares some two rectangles!All the painting happens based on that line in the code.
-
That's exactly what I'm explaining.
event->region()is the area that need to be repainted (the one under the notepad in my previous example). Ifrect(which is 1 image pixel zoomed) is inside that region then repaint it, otherwise just skip it. You can actually remove that if altogether, it's there just to make the paint faster to avoid repainting regions that did not need repainting -
Thanks.
That if-condition is for "the whole" painting I think. I removed the condition and it made the parameter event be left uselessly! I can't accept that condition is useful.
About another if-condition:
if(event->buttons() & Qt::LeftButton)in the mouseMoveEvent. Here it has used a bit-wise and (&) while the operator==will work too.Both sides are of the sate type (left, right or middle button). Why a bit-wise operator? (&)
And how could we convince ourselves that, that operator works correctly for that condition, please?
-
Hi
The bitwise & is used as the information is created that way. (using OR)
If multiple buttons were pressed, using == would fail even the Qt::LeftButton was actually also pressed.
So when a valued is created by using OR. the only correct way is to use & to check if that bit/bits is set. -
Thanks.
That if-condition is for "the whole" painting I think. I removed the condition and it made the parameter event be left uselessly! I can't accept that condition is useful.
About another if-condition:
if(event->buttons() & Qt::LeftButton)in the mouseMoveEvent. Here it has used a bit-wise and (&) while the operator==will work too.Both sides are of the sate type (left, right or middle button). Why a bit-wise operator? (&)
And how could we convince ourselves that, that operator works correctly for that condition, please?
@tomy said in Q_Properties in a Qt program:
I removed the condition and it made the parameter event be left uselessly!
It's not uncommon to have useless arguments. There is even a macro
Q_UNUSEDto suppress warnings regarding useless parametersAnd how could we convince ourselves that, that operator works correctly for that condition, please?
think of
ifas "it executes the next block if the argument is not 0.event->buttons() & Qt::LeftButtonwill return 0 only if theQt::LeftButtonbit is not set -
Thank you. But I still haven't got it.
The bitwise operators as their names express work on bits (0 and 1).
Do you mean that the statesevent->buttons()andQt::LeftButtonreturn are actually bits?event->buttons()returns a bit (0 or 1) andQt::LeftButtonalso returns a bit (1 or 0). Then that bitwise operator&, operates on the two states and returns the result according to the&&rule? -
Thank you. But I still haven't got it.
The bitwise operators as their names express work on bits (0 and 1).
Do you mean that the statesevent->buttons()andQt::LeftButtonreturn are actually bits?event->buttons()returns a bit (0 or 1) andQt::LeftButtonalso returns a bit (1 or 0). Then that bitwise operator&, operates on the two states and returns the result according to the&&rule?@tomy Please check the definition of http://doc.qt.io/qt-5/qt.html#MouseButton-enum, LeftButton has a value of 0x00000001
It is not a bit it is an integer.
If you do a bitwise & with for example 0x00000011 you will get 0x00000001 which is not 0 and as such true:0x00000011 & 0x00000001 = 0x00000001 // true 0x00000010 & 0x00000001 = 0x00000000 // falseThis has nothing to do with Qt - C/C++ basics.
