I recently upgraded my application from using a dynamic build of QT to a static. However, ever since the upgrade I am not able to:
Trigger mouse events: I am not able to click any widget, there is simply no animation (window is static).
Trigger keyboard events: I can not enter a value in the default focused QSpinBox.
Some remarks:
When the upgrade was performed, no style was set for the application (however in the dynamic build, there was a style). I fixed this by using application.setStyle("fusion")
I see the cursor of the QSpinBox blinking. In my experience this indicates that the GUI-thread is not "stuck" somewhere.
I found the problem: the GUI thread was not the main thread (this is also being logged)
Related
I want to save the focused window's title, i made this part but i dont know is there any QEvent which catches all (non-application) focusChanged event? Like switching from Chrome to Qt Creator. I made an alternative solution that checks in every second if the topmost window title has changed but this is so rude. I need cross-platform solution if possible.
EDIT
I am using QT 5.9.0
Quick answer:
Qt only has focus events for it's own windows and widgets. See http://doc.qt.io/qt-5/qfocusevent.html#details for start point.
There is no event for focus in other applications.
Details:
For multi-platform solution is needed to have more general point of view. On some (X window) systems where keyboard focus is in window under mouse. But that window becomes topmost only after click. On Mobile platforms there is only one active application. And application is not allowed seeing when other applications are activated. So in my understanding there is no full multi-platform solution.
Windows only extensions are in the Qt Windows Extras. http://doc.qt.io/qt-5/qtwinextras-overview.html. But there is nothing focus change related unfortunately.
I'm part of the SFML Team and we're currently looking into a feature to "request" window focus. The goal is to get very similar behavior across Windows, OS X and Linux.
For Windows one gets the rather simple SetForegroundWindow function via the WinAPI, which has a few condition as to how the window actually gets focus. The most important part to notice here is, that it only gets focus if it's from the same foreground process.
On OS X it's possible to get the focus for the active app only and otherwise let the icon bounce, i.e. notification.
Here comes the problem now, we'd like to get the same behavior on Linux as well, meaning the window should get focus if the window belongs to the active/foreground process and otherwise it should generate a notification. What would be the closest thing to that with X11?
There are already a few suggestions on the issue tracker of SFML, but none of them are actually implementing this behavior.
"User Story"
I guess developers can think of different things when being confronted with different technical names, as such here's the issue from a user perspective.
There are mainly two situations in which requesting focus is needed:
Sometimes when starting an application that uses a console window in the background, it can happen that the console window gets the focus instead of the actual GUI window. When this happens it's rather annoying for the user having to click on the window first. Since the console window and the GUI window are from the same application there's no harm done in switching the focus to the GUI window.
When one is writing an application that supports multiple windows, there might be situations where the application should decide which window gets the focus and again since the window belong to the same application there's no harm done in switching the focus from one GUI window to the other GUI window.
Further more if a different application has the focus/is being used then it's not okay to steal the focus and as such we just want to get the user's attention. For Windows that might be a blinking taskbar or for OS X that might be a jumping icon.
The current implementation seems to work fine on OS X and Windows, butwe're unsure about the X11 implementation. Thus the question is: How would one go about switching the window focus if the currently focussed window has been created by the same application that makes the focus request and otherwise create some kind of notification. For the notification we're/I'm not even sure if there's some generic way of doing it with X11.
In X11, "focus" means "the keyboard focus", that is, the window that gets the keyboard input. The window that has the focus is not necessarily in the foreground. This depends on your window manager focus policy. Most can be configured to have "click-to-focus" or "point-to-focus" policy. If you are interested in the keyboard focus, use XSetInputFocus. If you want to bring your window to the foreground, use XRaiseWindow.
It is OK to call RaiseWindow and XSetInputFocus once, when the application starts. It is also OK to bring a window to the foreground/set focus as a response to a user interaction with that or some other window of the same application. But it's not OK to do so as a response to some background event (time passed, file downloaded etc).
The standard X11 method of drawing attention to a window is setting the urgency hint. This will normally flash or bounce the icon, depending on your window manager. Do not forget to unset the hint when the user finally interacts with the window.
I think all of this has been discussed in the thread you have linked. I'm not quite sure which concerns are still left unanswered. Nothing can implement the exact same behaviour as with the other windowing systems, simply because X11 is not those windowing systems, and it's totally OK. X11, Mac OS X and Windows all behave differently and the users know and expect that. It would annoy me to no end if some application on X11 decided to behave exactly like it does on Windows, instead of toeing the X11 party line.
I'm displaying a popup window when the mouse cursor is over a certain widget and I'd like to hide this popup when the mouse leaves the widget.
To do it, I reimplemented leaveEvent(). This seems to work in all cases except when switching to another application by Alt+Tab. I figured out that I probably need to catch another event, but somehow I can't find the proper one. Can you suggest one?
The event you are looking for is QEvent::ApplicationDeactivate: "The application has been suspended, and is unavailable to the user".
You can install an event filter on your QApplication instance to catch this event. See the documentation for QObject::installEventFilter(QObject*) for more details how this works.
Since Qt 5.2 the QEvent::ApplicationDeactivate event is deprecated. The correct way to identify when an application is deactivated in Qt 5.2 (or later) is to use the QGuiApplication::applicationStateChanged(Qt::ApplicationState state) signal.
still relatively new to Qt (and to stackoverflow as well) but succeeded over the last weeks to replace our old obsolete-when-new GUI code with Qt and improve several things along the way as well. Now however I am running into a problem I so far have not been able to google my way out of.
Some background:
Application has an opengl main window which is created outside Qt (most of this application is completely outside Qt), Qt windows are only used for (development) subfunctionality, just GUI.
I am calling processEvents() from the main loop each frame.
Using locally built Qt 4.7.4 on both platforms.
Everything works fine on linux. The Qt windows behave properly and I can interact with the application/simulation in the main opengl window through mouse and keyboard just as was always possible.
However, when I applied the same changes to incorporate Qt on windows the mouse no longer works in the main window. Keyboard does, but our mouse code never seems to get any WM_INPUT events. When I disable calling processEvents() the mouse works fine again. (but then obviously the Qt windows won’t work properly)
It seems Qt is catching mouse events intended for the main window and throwing them away/forgetting them instead of delivering them to the main window.
Unfortunately I haven’t found anything that points to this being a common occurrence (with a common simple solution).
I did find http://qt-project.org/forums/viewthread/502 referencing an issue with mouse events but the resolution mentioned there of compiling Qt with _WIN32_WINNT=0×501 defined does not make any difference.
Any insights would be highly appreciated!
When I use Spy++, I notice that mouse entering a button triggers a series of WM_TIMER .
How is Windows doing this? Is it requesting that the OS notify it or call a function pointer after X milliseconds, or does the widget register its own timer proc?
The reason I want to know this is because I'm building a game gui api in C++ and want to incorporate this sort of mechanism.
Thanks
I believe that the button's window procedure is using the SetTimer function to register the window for notification via a WM_TIMER message. You can use SetTimer either to call a specific function after time elapses, or to trigger a WM_TIMER message with the specified information.
MS Windows's GUI animation capability is very limited. You can say nothing if you had known real animation capable OS like Mac OS X.
Windows GUI is a composition of various child windows which has own event handler routine and drawing code. Very clumsy and performance inefficient of course, only provide easy access to ordinary developers.
In short, I want to say that MS Windows is the least recommendable reference for developing a game GUI framework. If I have a opportunity to develop new GUI framework, first thing I would devise is a mechanism to separate input event handling and graphic drawing for consolidated screen drawing, like game programs do.
Have a look at this:
http://www.rawmaterialsoftware.com/juce.php
(source: rawmaterialsoftware.com)
Game API's normally do their timing in the actual message loop of the application as most games draw sprites directly on the surface of the window, rather than using individual child windows.
Self animating controls that are build as child windows can schedule WM_TIMER messages to themselves via SetTimer, normally to process short term states - in your case the Button has probably used the TrackMouseEvent API to be notified via WM_MOUSELEAVE when the mouse leaves the button.
To allow more advanced animations in form based applications, Microsoft has introduced the Windows Animation Manager.