[Done] QSplitter/widget resizing problems.



  • 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.



  • 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.)



  • 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:

    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 :)



  • 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"


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.