[Done] QSplitter/widget resizing problems.

[goblincoding]

Hi all,

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:

gobchartswidget.ui
gobchartswidget.h
gobchartswidget.cpp

Any help will be greatly appreciated...I have this feeling that it's something trivial I'm missing.

Thanks!

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]

I don't know for sure, but as far as I am understanding, you should give setStretchFactor() a try

[goblincoding]

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 );
@

[goblincoding]

I'm still no closer to solving this despite numerous attempts. Anybody?

[goblincoding]

Closed as no longer relevant.

(Decided to try a different combination of splitters and widgets. Looks promising so far.)

[andre]

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]

[goblincoding]

I mean no disrespect, but marking it as "closed" made more sense to me for two reasons:

1. The original problem hasn't been resolved, I have decided to go a different route.
2. 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]

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?

Edit:
As per suggestion on the moderators channel, I changed the tag to "DONE". Done as in the meaning normal in Qt: "Lost interest"