Apparently separator will always fill the height of the toolbar (or width for vertical toolbars). You can limit it by adding top/bottom margins, so if your toolbar is 40px and you want the separator to be 30px add 5px top and bottom margins.

Any idea?
I found that I could use Qt::CustomizeWindowHint to remove shaking if it was possible to recolor that white bar on top — but Windows 10 doesn't have that option.
b9db0863-69eb-480d-9d18-c6bed295e5e2-image.png

I see. Thank you.

@Christian-Ehrlicher Ok. I understand, I will add my check boxes in a different function and not during showEvent().

I tried setting layoutSizeConstraint to different values for the vertical layout, the QScrollArea as well as for the widget itself, because of QScrollArea my widget is always resized to a small size when shown for the first time, this is why I tried to add and resize the widget during showEvent() myself. According to Qt's documentation:

If a scroll area is used to display the contents of a widget that contains child widgets arranged in a layout, it is important to realize that the size policy of the layout will also determine the size of the widget. This is especially useful to know if you intend to dynamically change the contents of the layout. In such cases, setting the layout's size constraint property to one which provides constraints on the minimum and/or maximum size of the layout (e.g., QLayout::SetMinAndMaxSize) will cause the size of the scroll area to be updated whenever the contents of the layout changes.

But this is not working for me, I am setting the size constraint to QLayout::SetMinAndMaxSize but the QScrollArea remains at the minimum size when shown for the first time.

SetMinimumSize() does not work for me. I think it is because I change the window's position. However, the problem was in my form file. For an unknown reason, it changed the window's size to 802x600 when I was checking for 800x600. Maybe there was some another way out, but now all works just fine.

Calling the base class implementation did the trick. Thank you again!
I didn't try the resizeToContents as some cells shouldn't be sized to their content in some context.

@SGaist That's a fair question and to answer that it's because on the actual dock widget itself, in the production code, there are two widgets that get placed inside the dock widget itself. The topFrame contains the layout for the QTabWidget as you have pointed out. The code that is not present, botFrame contains another QGridLayout. These two then get placed inside the QGridLayout which is the layout of QGroupBox.

Then to answer Why am I subclassing a layout to put widgets in it? I guess this is a personal decision and can be argued either way. For now, I will say that you are correct, that the Widget should manage the way the GridLayout adds widgets to them. However, I will argue that since QGridLayout is it's own class; the Widget does not "own" the widgets, rather, the layout owns the widgets since QWidget does not have a addWidgets function in it. Therefore, QGridLayout owns and is responsible for the Widgets that it owns. Hence the decision that the QWidget is the parent, which has a QGridLayout, which the QGridLayout as the Child, has the widgets that belong inside of it.

This is a programming decision that I made with these arguments.

@YouDoItWrong said in Random crash on window resize.:

By "bugreport" you mean code and error in this "head topic forum post"?

No, bug report in Qt bug tracker: https://bugreports.qt.io/secure/Dashboard.jspa

We found a solution to that bug. The Cocoa window itself isn't set to non resizeable.
If you do this, everything works as expected.

class MainWindow : public QMainWindow { public: explicit MainWindow(QWidget *parent = nullptr) : QMainWindow(parent) { //this will get rid of the size grip widget showing setFixedSize(500, 500); } void mousePressEvent(QMouseEvent *) override { std::cout<<"mouse pressed"<<std::endl; } }; int main(int argc, char *argv[]) { QApplication a(argc, argv); MainWindow w; NSWindow* window = [(NSView*)w.window()->winId() window]; //IMTPORTANT. Otherwise the lower right mouse events will not be passed on correctly by cocoa window.styleMask &= ~NSWindowStyleMaskResizable; w.show(); return a.exec(); }

@AloyseTech IIRC hidePop() will reset the Popupwidget, so maybe hijack the add/remove process.
Call hidePopup before adding are removing item and call showPopup afterwards?

Hi and welcome to devnet,

What version of macOS ?

Did you also check whether the latest beta of 5.12 has the same problem ?

@jsulm
I got this, thanks

Use https://doc.qt.io/qt-6/qwindow.html#startSystemResize instead. You can call it from QML.

@raven-worx

I tried the following but didn't work out..

QGraphicsPixmapItem* item = new QGraphicsPixmapItem(QPixmap::fromImage(qImage, Qt::AutoColor)); m_ViewerScene->addItem(item); QGraphicsRectItem* rect = new QGraphicsRectItem(m_BoundingBox); m_ViewerScene->addItem(rect); rect->setParentItem(item); m_ViewerScene->update(); //add the resized QGraphicsPixmapItem to the pixmap item->setPixmap( item->pixmap().scaled(QSize(128, 32),Qt::IgnoreAspectRatio, Qt::SmoothTransformation)); qInfo()<<"Rect resize props:::"<<item->childItems()[0]->boundingRect(); m_BoundingBox = item->childItems()[0]->boundingRect();

later I'm drawing box, on the image in an other viewer, with m_BoundingBox.

0_1527498444379_Untitled.png
The grey area within the blue rectangle will be resized to 128 * 32, and then the red rectangle would be added on the resized image. How to get the co-ordinates of red rect on the resized image?