QRect should change its way to compute the width and height, especially in QRect::normalized().

As we know, in QRect, width() = right() - left() + 1.
This is fine in most cases, or specifically, when right() > left() - 1.

When right() < left() - 1, we get a QRect with negative width. But no worries, we can correct it by calling normalized().

For example:

QRect rect1(QPoint(3, 3), QPoint(1, 10));

rect1 has width -1 (by 1 - 3 + 1). rect1.normalized() will return a QRect with width 3. No problem. We get it corrected and get a QRect which is the bounding rectangle of the corner points.
But this transition (from -1 to 3) is strange, isn't it? What? Not strange at all? OK, let's look at another situation.

When right() == left() - 1, we get a QRect with 0 width! How did that happen?! Even a rectangle that starts at (0, 0) and ends at (0, 0) has a size of (1, 1)! But don't worry, we've got magical normalized().

QRect rect2(QPoint(3, 3), QPoint(2, 10));

rect2 has width 0 (by 2 - 3 + 1). However, this time rect2.normalized() does nothing but returns the same QRect as rect2. Because normalized() only works for negative width or height, excluding zero width or height.

SO, I think Qt should change its way of implementing QRect::normalized(), as well as QRect::width(), QRect::height(), QRect::size(), etc. The same to QRectF and other similar structures.

Take width() for example.

Original:

int QRect::width() const
{
    return x2 - x1 + 1;
}

My suggestion:

int QRect::width() const
{
    if (x2 < x1)
        return x2 - x1 - 1;
    else
        return x2 - x1 + 1;
}

This way, we can never get a zero-width QRect. And rect1 will know its width is -3 instead of -1. After normalized(), a change from -3 to 3 is surely more intuitive than that from -1 to 3.