Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
[Done] QSplitter/widget resizing problems.
I've got a widget set up in such a way that a horizontal splitter is contained within a vertical splitter and both of these are set on a widget. The problem I'm experiencing is that I have to do a very hacky job of ensuring the widgets contained within the splitters resize to the exact proportions that I want. I've tried various combinations of overriding the main widget's resizeEvent(), using setSizes() on the splitters and even adding spacers to the splitters (i.e. widget | spacer | widget | spacer | widget ) etc.
The best I've got so far is to re-implement showEvent() on the parent widget, setting minimum sizes on the splitter's child widgets and then in resizeEvent() setting maximum sizes on the same widgets. This works nicely when a user maximises or minimises (double-clicking) and also when the user resizes (by dragging) the widget along only one axis. However, there is a resize delay when dragging a corner (increasing both width and height simultaneously). Furthermore, it feels to me as if constantly resetting the widget's maximum sizes is a rubbish way to go about this (and resize() doesn't work, I've tried).
Long story short, there is a complete test project available for download <I removed the link as it's no longer publicly accessible>
The relevant files are contained in the "widget" folder:
Any help will be greatly appreciated...I have this feeling that it's something trivial I'm missing.
EDIT: Perhaps I should mention that the test project is all of ~70kb and you can literally just open the .pro file, compile, run and play around to see what I mean.
raaghuu last edited by
I don't know for sure, but as far as I am understanding, you should give setStretchFactor() a try
Thanks for the reply, but I do use setStretchFactor() to no avail (from gobchartswidget.cpp):
ui->horizontalSplitter->setStretchFactor( 0, 0 );
ui->horizontalSplitter->setStretchFactor( 1, 1 );
ui->horizontalSplitter->setStretchFactor( 2, 0 );
ui->verticalSplitter->setStretchFactor( 0, 0 );
ui->verticalSplitter->setStretchFactor( 1, 1 );
ui->verticalSplitter->setStretchFactor( 2, 0 );
I'm still no closer to solving this despite numerous attempts. Anybody?
Closed as no longer relevant.
(Decided to try a different combination of splitters and widgets. Looks promising so far.)
andre last edited by
Topics are not closed by just calling them closed. They can only be closed by moderators, and that is only done if a topic gets out of hand. There is no reason to do so in this case, so I'm changing the topic tag to [Solved]
I mean no disrespect, but marking it as "closed" made more sense to me for two reasons:
- The original problem hasn't been resolved, I have decided to go a different route.
- I always thought that the whole point of adding the "solved" tag was to help refine search results. Qt users searching these forums for related issues will now come across a thread that is entirely useless to them so the "solved" tag here creates a false impression of success.
"No longer applicable" would make even more sense, but I thought that was a bit long :)
andre last edited by
Hmmm... ok, reasonable points on why "Solved" is not the best tag to use here. OTOH, "closed" as a specific meaning too, and that does not apply here either. I'll try to think of another tag to use, ok?
As per suggestion on the moderators channel, I changed the tag to "DONE". Done as in the meaning normal in Qt: "Lost interest"