I discovered that in the latest Qt versions (currently I use 5.4.1 but it was the same in 5.2) if I add several items to a QComboBox and I position the mouse cursor in specific positions it will scroll itself which is really annoying ... I think.
I've got a very simple GUI created in Qt Designer. It only contains one QComboBox. I added a lot of items (30) to it to be able to check this bug. If the first N items are visible it cannot be reproduced, but if I scroll down a little, and then position the mouse as on the image with the red dot and starts moving the mouse around it then the auto scrolling started.
It does not seem like a great bug, but when you just want to move the mouse cursor away and it results that the list scrolls away.
UPDATE:
I found out that it can be only reproduced if the first item in the list is an empty string. Without that it works just fine.
It is a bug in the version of Qt 5.4.1. Reported.
Related
I think I understand the reasoning behind Wayland preventing windows from being manually positioned but there are a couple of instances in my Qt 5.15.2 application where I really need to have either some or absolute control over the position:
In the first instance the window is a pop-up. I'm using a QMainWindow so I can have it borderless with rounded corners, a coloured background and a transparency. I need it to pop-up when I hover over a certain element on my QGraphicsScene but want to ensure that when it appears it is close to the QGraphicsScene element in question but does not obscure it. Using a call to QMainWindow::move was perfect pre-Wayland and works fine on Windows too.
In the second instance my application has a number of windows which the user may open and close over time. The first time each one opens I don't care too much where it is positioned but if the user moves it before closing it then the next time the user opens it I want it to reappear where the user previously left it. Again, using the move() method of the various things that inherit from QWidget was perfect pre-Wayland.
Does anyone know of any work-arounds that would solve either of these problems under Qt on Wayland? It seems to me that neither is a particularly uncommon requirement and if Wayland won't let me set a specific position it might have a way of achieving something similar (e.g. a way of telling the compositor to position something near something else without obscuring it) and hopefully that maps onto something in the Qt API.
After upgrading to qt version 6.2 from qt5 I faced the problem with starting the app in the maximized mode. The widget is first painted with it's normal size and then repainted fine. The intermediate state is shown on the gif below:
The code of the app from the giff comes together with Qt (my version is Qt-6.2.3) and called "styles" (path is Qt/Examples/Qt-6.2.3/widgets/widgets/styles) or can be found on the qt.io. I have just changed widget.show() to widget.showMaximized() in main.cpp.
I figured out that sometimes widget starts fine, but this is rather rare. Also the more complicated widget is, the more time it takes to correctly paint it on the first show.
In the example from the gif the start is so quick that it is almost invisible, but in the heavy app I'm working with this slow startup really catches the eye.
If this can not be easy fixed, does anybody have any idea how to mask this behaviour? I thought about painting the widget on the virtual framebuffer and moving it back to the main display right after first show, but I did not find any easy means to create it in c++.
Any help is appreciated.
EDIT:
I finally reported a bug to qt developers.
See QTBUG-104357
I'm still trying to do some pretty basic stuff with qt, and it's been a struggle. I'm specifically targeting for Mac. My current problem is getting the forms to not suck.
The simple problem. Create a new MainWindow app. Go into the Qt Creator (open Forms -> mainwindow.ui).
Drag 3 labels into place. Then I dragged 2 Line Edits and for fun, a Dial, but that part probably doesn't matter.
Click the main window and then tell it to use Form Layout. Within Qt Creator if I resize the window, my various line edits expand to fill the available space, exactly like I want.
Run the app. All the line edit fields are a fixed length, very short (if I don't override their minimum width), and do NOT resize as I resize the window.
Three quarters of the reason to use Form Layout is for resizing capability.
I've tried clicking on the central widget before setting to Form Layout: no change in behavior.
I do get reasonable behavior if I use a grid layout, although I have to add a vertical spacer at the bottom or my dial resizes crazily as I play with the window size.
So... Am I just doing something wrong with Form Layout? Or does it not work well on Mac and I should use Grid Layout instead?
I really miss Motif's XmFormLayout. It took time to set all the constraints, but I could make my forms do exactly what I wanted. Ah, but so 1990s.
On the panel to the right where you can see the objects, click the centralWidget. In the property panel, scroll down until you get to the layout properties of the form layout. Set the layoutFieldGrowthPolicy to ExpandingFieldsGrow.
By default, the line edits are not growing to fill the available space on macOS because they are not supposed to. This is some sort of macOS UI guideline. QFormLayout follows the platform conventions by default.
It would also be nice if I can figure out how to NOT necessarily expand everything to full width. I have a few Line Edit widgets that I'd like to keep short. They're going to hold TCP port numbers.
For those, set the Horizontal Policy property (it's grouped inside the sizePolicy property group in the properties panel) of the affected line edits to something suitable. In this case, probably to Fixed, but look up the documentation first of what each setting does.
I have ported my application to be built with Visual Studio 2013.
After building it, I found that the resizing mouse shape is interchanged.
The first shape of mouse pointer appears when I want to resize a vertical splitter and the second one appears when I want to resize a horizontal splitter: this behavior is new. In the previous release of my tool, the first one appears when I want to resize a horizontal splitter and the second one appears when I want to resize a vertical splitter.
I didn't change anything in the code. How can I make it to reproduce the old behavior?
We found that we use a third party MFC libraries and we use the cursors from them; in the new release, they have swapped the names of the icons of the cursors and this is the root cause of this problem. As a workaround, we have swapped the names to give the old behavior.
I have a top-level Qt widget with the FramelessWindowHint flag and the WA_TranslucentBackground attribute set. It has several children, each of which draws an image on it. They are not in a layout. Instead, I simply move them around when something changes (it is not user-resizable).
There are two states to the window - a big state and a small state. When I switch between them, I resize the window and reposition the children. The problem is that as the window resizes, a black box is briefly flashed on the top-level window before the images are painted over it.
The problem goes away if I disable Aero. I found brief mention of this problem being fixed in an article describing a new release of Qt (this release is long past), but it still doesn't work.
Any ideas why?
Thanks!
I don't have experience with Qt specifically, but I have worked with other windowing toolkits. Typically you see this kind of flashing when you are drawing updates directly to the screen. The fix is to instead use Double buffering, which basically means that you render your updates into an offscreen buffer (a bitmap of some sort, in the purest sense of the word), and then copy the entire updated image to screen in a single, fast operation.
The reason you only see the flickering sometimes is simply an artifact of how quickly your screen refreshes versus how quickly the updates are drawn. If you get "lucky" then all the updates occur between screen refreshes and you may not see any flicker.