How to properly handle toolbar dragging

[Snow-Okami]

I had a similar issue to the closed issue here: #1

I finally got a toolbar working (I changed it to a QWidget however), but I have an issue that I just cannot solve and would greatly appreciate any help. When dragging the toolbar, it works the first time, but after that the functionality breaks. I have tracked this down to the layout of the toolbar changing (it seems to shrink to the absolute minimum in the top left corner) each time dragging begins. Dragging then breaks unless you put the mouse exactly in the microscopic spot on the left of where the buttons for the layout are now seen (in the top left).

The only way to restore dragging functionality is to minimize & restore, maximize & restore, or resize the window. After this dragging works again, but then it breaks after one drag due to the same resizing issue. The buttons and tool bar positions stay the same but internally something shifts. I figured this out by debugging the cursor position to tell me what widget the cursor is over before and after a drag.

How can I stop this behavior? I have tried nearly everything. The only way I can see in solving it, is to trick the window during dragging or after a drag into simulating a resize to the same window size (so no flickering or visual oddities occur) to prevent the layout from falling apart internally. I am completely new to Qt, so as you can imagine, this library has been a HUGE help to me.

Here is a function I call that I tried to get to work to solve the problem but it does not solve the issue (it is several things I have tried to simulate what was stated above):

void QWinWidget::ForceUpdateToolBarArea()
{
    p_Widget->maximizeButton->setChecked(true);
    p_Widget->maximizeButton->setChecked(false);
    
    p_Widget->titleWidget->update();
    
    p_Widget->titleWidget->updateGeometry();
    
    p_Widget->show();
}

A sample of code on how to properly implement the toolbar would be of great help. As a side note too, a proper example way of handling putting a .ui form into the widget would be great, as I believe my way to be improper (but it works).

[dfct]

I'll whip up a sample that includes a working toolbar, and in the process see if I encounter the same issue you're seeing with the weird drag functionality.

[dfct]

There's a bug in the current hit test check for the toolbar, my bad! That's why you're seeing the drag issues. Foiled by braces.

[dfct]

As of 36c6451 the drag issue is fixed and there is sample code for the toolbar + min/max/close buttons on Windows.

[Snow-Okami]

Indeed that was the issue, thanks! I was actually playing around with the logic there and still never came to the conclusion that the logic needed to be that way to solve the issue. Thanks! The toolbar code is incredibly helpful. I had an issue with some overlaps with my other widgets on the form but was able to solve it with: setAttribute(Qt::WA_TransparentForMouseEvents); I didn't know this existed.

Is it possible to do the same thing with how to properly integrate a form (.ui) file into the window? These snippets are incredibly helpful.

[dfct]

@Snow-Okami it's certainly possible to do the same thing with a .ui, but I don't have an example on hand. I haven't used .ui as the base for my GUI work in a long while myself, but I don't think it'd be too ridiculous? It should just be replacing the widget used via widget.h with the widget that your .ui file generated instead (& optionally similarly with the toolbar + buttons)

[Snow-Okami]

Thanks! I think the way I am handling it might be the best way to go about it. If anyone in the future wants a sample you can see my code here to see how I dealt with the forms.

https://github.com/Snow-Okami/phantom-app/blob/master/frameless/src/widget.cpp

Also the widget.h file. The .ui file must be included in your .pro file.