After successfully porting my Qt based windows application to OSX I noticed a problem. Widgets are behaving rather oddly, with not a single error being thrown and exactly the same code used on Windows.
Widgets, such as QTreeView and QListView, when clicked on show a blue border around them. When in this state that particular widget becomes unresponsive to clicks. That is until another widget is clicked on, becoming "active" with a blue border. When the first widget is clicked on (the non-active one) it reacts, but then gets a blue border and does not react to any input.
Other strange behavior, is when these widgets are popped out of the main application window, they stop rendering, as in you get a blank, floating window. When docked back into the main window they return to normal.
Since I cannot reproduce this behaviour on Windows with the identical code, it must be Qt on OSX, or OSX itself.
I have not a clue as to what is causing this.
By the way I am using Qt 5.0.2
I appreciate any and all help.
More info: I had'nt noticed this but I am getting the output QBackingStore::flush() called with non-exposed window, behavior is undefined.
I'm not sure if this is a result of my widgets disappearing out of there containing dock widget when undocked, or is the source of the problem
So you're all aware this was fixed by upgrading to Qt 5.1.0 beta.
I cannot explain why it just works when using a new version and not with an older version. My own code between the two is identical.
Related
There is a Qt window, which hosts many widgets, among them is one QOpenGLWidget widget to plot waveform. This works well on almost all machines, but there is one strange case with a machine having an Intel OpenGL graphics version 3.3.0 - Build 21.20.164678.
This is the good behavior on almost all machines:
And this is the strange case, wherein title text goes beyond top border of the window, and to click a button, we have to offset mouse pointer above the rendered position of that button. Text is also a little bit blurry. This problem does not happen if I replace the OpenGL widget with another non-OpenGL widget:
Any suggestions to fix the issue?
I am currently using a Mac to test my software, I have a fullscreen Qt window that opens a floating Qt::Tool on top of it. I would love for the Qt::Tool to be linked to the fullscreen window, however when switching between desktops (three-finger swipe), the Qt::Tool is displayed on the other desktops although its parent window is in fullscreen in another desktop.
Is there an event that handles switching desktops so that I know when a window is no longer in focus and hide its child windows/tools?
Thank you very much in advance.
You are probably using some set of window flags that leads to this behaviour. Try to change those and see if you can get it to work like you want. I bet Mac handles one of the window flags you set in a special way such that it carries across virtual desktops.
I have two widget inside of one window.
First widget is a program main menu.
Second one open when user presses 'New project' button.
I have enabled DPI via QT_SCREEN_SCALE_FACTORS + setAttribute(UseHighDpiPixmaps).
I have icons dynamically scaled for second widget when I move app from one monitor (windows dpi 100%) to another monitor (windows dpi 175%).
But first one (main menu) does not work this way.
It just preserves 2x icons without any respect to DPI.
I found this by marking 2x icons.
Also I was not able to reproduce this on the toy example.
Could anyone please point me the right direction?
I have a QMainWindow with three QPushButtons (arranged in a QVBoxLayout in a QWidget). All have the same properties, except objectName, icon and iconSize. All are enabled and have two icons, one for normal and one for disabled.
When I start my application, always the top most icon shows the disabled icon (but is working, so it is enabled) the other two are fine. As soon as a focusable control in that window gets the focus, the icon changes to the active one and everything is fine.
Calling update or repaint in the showEvent of the window doesn't help either.
I'm using gcc 4.8.1 and qt 5.1.0.
Any ideas how to handle this glitch?
Update: It gets more strange: Starting the program, the icon shows disabled, getting another application the focus, the icon shows enabled, bringing the window on top again without giving it the focus (e.g. by using the task bar) changes the icon back to diabled. Clicking a control in the window, which can have focus will fix it again.
Well, well I finally got it. I just set the focus manually in the code and realized, that the icons were set in a wrong way. If a button was currently focussed it displayed the disabled icon. I had messed up the different button states and too many states got the disabled icon.
I have a qt application that is comprised of a main window and a settings window that I am trying to port to Qt5.
I use QWidget::setParent() to set my settings window exactly on top of(and cover) my main window, and prior to using qt5.1.1 (the previous version I used was qt 4.8.5) this method worked fine.
The problem I have right now is that the settings window is being displayed correctly but almost all mouse events(minus the mouse over on some of the buttons) are being passed directly to the main window which is underneath.
I have tried setting different flags for the settings window to no effect.
This issue does not reproduce on windows.
I've being searching for a solution to this problem for some time now.
I am using qt 5.1.1 on MacOSX 10.7.5
Your problem is with overlapping siblings. When you reparent the settings window, it has various siblings inside of the main window that overlap it. This seems to have undefined behavior, as you've just learned. Your window is not added to any layout merely by being reparented. If it was added to the layout (except for stacked layouts), you wouldn't have this problem, and of course it wouldn't look right either.
A portable solution would involve using either:
A QStackedLayout as the base layout within the main window. Note that this won't work for QMainWindow, QScrollArea and similar windows that don't have container layouts applied directly.
A QStackedWidget as the base widget class, with your QMainWindow or similar class inserted into it.
In both cases, you temporarily insert your settings window into the stack, and flip the pages.
Note that this behavior is questionable from user experience perspective.