Important: Please read the Qt Code of Conduct -

Cannot seem to make toolbar be vertical

  • @mrjj
    Well that too is odd, because I don't see the image under default Firefox from Linux nor IE 11 from Windows.... I do see it under Chrome for Windows... I wonder what the setting is? OTOH, I do see your two "MainWindow" screenshots in all, however...

  • Lifetime Qt Champion


    Maybe its just with animated gifs ?
    Do you see this ?
    alt text

  • @mrjj
    Yep! But not Snoopy. Somehow I guess it's the source of the Url...

  • Lifetime Qt Champion

    That would also make sense :)

  • @mrjj
    Well, good news, and bad news!

    I wonder whether you would be kind enough to investigate behaviour for me? The underlying problem seems to be to do with saving & restoring main window state, and is a bit weird....

    First, starting from scratch my Python code for vertical, left-hand side toolbar is indeed working fine, in itself, just like the C++ code. So that's good.

    The stakeholder has now decided that the toolbar is to be setMovable(True) after all (but still setFloatable(False)).

    At this point, I can drag & dock toolbar to all 4 sides fine. As you know, when you drag toolbar main window "expands areas" to visually show where it can be docked, and all 4 are shown.

    We save & restore main window layout (see below). If I have dragged toolbar to either left or right vertical all is well, after re-run program and restore toolbar can still be dragged to all 4 positions.

    However, if I drag toolbar to either top or bottom horizontal, after re-run program and restore toolbar it is not only possible to drag it to top or bottom, never to left or right, and only the top & bottom areas "expand" to allow drop.

    The only way to then rectify this is to delete the saved layout-state .conf file externally. Then all reverts to original good behaviour.

    Skip all following stuff about save/restore, and go straight to next IMPORTANT EDIT afterward.

    The code outline is:

    1. Take your C++ as starting point.

    2. On window close:

      QSettings.setValue("main_state", self.saveState())

    3. In constructor, after having constructed toolbar & set its options:

       mainState = Settings.value("main_state")
       if mainState:

    That is what causes this strange behaviour. I'm wondering whether this must somehow to be to do with, because it's as though it's only allowing top & bottom now [EDIT: Just verified self.toolbar.allowedAreas() == Qt::AllToolBarAreas always, both before & after any restores.]; unless it's something to do with the setOrientation not supposed to be used with QMainWindow.... [EDIT: Just removed the setOrientation completely, doesn't seem to be needed (presumably addToolBar(Qt::LeftToolBarArea) is dealing with this for main window, perhaps why they say don't use setOrientation for main window). But no difference for this problem behaviour, so you can try with or without according to me.]

    My head hurts. If you fancy looking into this you know I'd be most grateful!

    OK, forget about all the stuff to do with saving/restoring. It's not that. Quite simply, look at the QMainWindow::addToolBar(Qt::LeftToolBarArea, toolbar);:

    • If you use Qt::LeftToolBarArea or Qt::RightToolBarArea, you can drag & drop toolbar to all 4 sides.
    • But if you use Qt::TopToolBarArea or Qt::BottomToolBarArea, you can never drag & drop to left or right side, only top or bottom.

    Period. Given that it can support all 4 drag sides after starting at left or right, yet cannot support drag to left or right if starting at top or bottom, is this a bug??

    [EDIT: Oh dear, this only appears to be the behaviour in my app, not in standalone test, I'm investigating further...]

  • Lifetime Qt Champion


    Will do, but first this evening :)

  • @mrjj
    Cheers, I'll buy you a drink ;)
    I did begin to wonder whether you do anything other than answer posts here during working hours... ;-)

  • Lifetime Qt Champion

    oh, i do. ;)
    Its just my old pc (2011) is getting tired so with new c++14 and 64bit virtual machines,
    it takes a bit to compile and then learning more Qt is always nice.

  • @mrjj
    If & when you have time to look at my latest edit to my question, you'll see we can skip anything to do with save/restore. The problem seems to be quite simple now: you cannot reposition a toolbar to left/right if it starts at top/bottom, but you can the other way round.....??

    [EDIT: Oh dear, oh dear, this is not a problem in the standalone test, only in my actual app. More investigating... :( Any idea at all what might cause this behaviour for me to look at?]

  • Lifetime Qt Champion

    Sadly no. Normally all areas are allowed.

  • @mrjj
    OK, once & for all, I think I understand what the situation is now(!)

    1. You start with a horizontal toolbar on the main window.
    2. You have other layout/controls on the page, which take up a lot of horizontal layout. This effectively gives the page a minimum width, below which you cannot resize the window.
    3. Your window width is a bit more than the minimum, but not a lot wider.
    4. You attempt to drag the toolbar from horizontal at top to vertical at side.

    The problem here is that there is not enough space across the width of the window to allow the vertical "docking" area for the toolbar to appear, because that would shrink the window's horizontal layout content below the minimum it needs. So you cannot drag & drop the toolbar to left or right.

    In some shape or form, if you start out with the toolbar vertical it displays it there, but once it has been dragged to the top horizontal, it no longer lets you revert to vertical, which didn't really fit.

    I can see the problem. Of course I was not aware I was in this situation while I developed/tested. It's a nasty one for my end users, because once dragged horizontal it's not clear why they find it impossible to revert to vertical. But at least I know now, and they can be told to widen the window before attempting to revert to vertical toolbar.

    Thanks for all your help!

  • Lifetime Qt Champion

    Oh that was a tricky one.
    Good debugging !
    So due to Min. values, once removed/dragged,
    you cannot drag into same place as the layout prevents it ?
    I assumed mainwindow would sort of reserve some space for it but that is clearly not the case
    it seems.

  • @mrjj
    Yes that's the gist. I think there might be a special case where the toolbar starts off vertical when it shouldn't have enough room horizontally really, but just ignore that. Once you're into dragging, if there isn't enough horizontal (or vertical) space given the page content minima for the destination of the drag, quite simply Qt does not open up the "blued reception area" to drop into, and when you release the mouse the toolbar reverts to where it was.

    Which I found confusing, I didn't understand what was going on, and I just didn't realise my (resizeable) main window size happened to be too close to the minimum width in the first place. Now I do, and I can understand Qt's behaviour, even if it's a little "non obvious". :)

  • Lifetime Qt Champion

    @JNBarchan said in Cannot seem to make toolbar be vertical:

    "non obvious". :)

    It was very sneaky IMHO.
    I thought that all the use of central widget would always allow room for
    docks/toolbars. !

  • @mrjj
    Remember I'm a noob. But if it always "allowed room for moving the toolbar anywhere", you'd have permanent reserved empty space always, which doesn't seem right. At some level my content's layout (I didn't write it) --- even the "central widget" --- has some minimum width, and if the window is narrowed down to somewhere close to that there just isn't room across the main window to allow for the toolbar to now take up extra width space by being dragged to vertical. Which makes sense.

  • Lifetime Qt Champion

    Im going to see if i can reproduce it/get the same effect :)

  • @mrjj

    My main window has half a dozen "filter controls" laid out like:

    Label1:     Label2:     Label3:   ...
    <input1>    <input2>   <input3>   ...

    where the <input> controls, I think, have a decent minimum width. They don't move down to the next line or anything when I resize, so that, I think, is what gives it an overall considerable minimum width for the main window.

  • Lifetime Qt Champion

    ok so its not just one big widget. good info. :)

  • @mrjj
    No. But of course those widgies will doubtless be positioned/added onto some other widgey, etc..... Ultimately I think there are vertical/horizontal vbox layouts. I note the starting point seems to be:

        # Configure main widget
        self.centralWidget = QtWidgets.QWidget(self)
        self.centralLayout = QtWidgets.QVBoxLayout(self.centralWidget)
        self.centralLayout.setContentsMargins(0, 0, 0, 0)
        self.pageStack = QtWidgets.QStackedWidget(self.centralWidget)
        # Set up layouts

    so that gives a "glimpse" of what's going on....

  • Lifetime Qt Champion

    Ok it was easy to reproduce.
    just with one widget in central and min size of 200.
    if you reduce mainwindow size till it cant get smaller, you are not
    able to dock the toolbar back again. (to the side)
    It seems to function in top/bottom.

  • @mrjj
    Thanks :)
    You can also reduce mainwin width to minimum + ~1cm and it will still happen, depending on width of required vertical toolbar, so doesn't only happen when window at minimum width.
    That's what I've been experiencing for two days, but I didn't know what was going on!

    It seems to function in top/bottom.

    Yes, in this case. I haven't tried (maybe you have), but it might happen if page has a minimum height on its widgets and not enough room for even one-line horizontal toolbar at top, but harder to set that up.

  • Lifetime Qt Champion

    My sample had min as 200x200 and i just tried now again.
    If no toolbar from beginning at top and you resize.
    You cant dock back either.
    Oddly enough add space with setContentsMargins(0, 0, 0, 0)
    Didnt help. Even a small strip of space was seem.
    I assume its due to events not reaching mainwindow.

Log in to reply