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!
Related
I'm writing a c++ application that creates a GTK3 window at some point, while also running X11 code in other places.
For the pure X11 part i'm using XOpenDisplay() to open a display.
Running the X11 part and opening a GTK window afterwards works fine. Also running the X11 part multiple times is no problem as i release the display there using XCloseDisplay.
The problem i'm facing occurs when i try to run the X11 code after gtk has been initialized (to be more specific, calling XOpenDisplay() after the gtk initialization).
I'm suspecting that after running gtk_init() the display is never being released, even after gtk_main_quit().
I didn't find anything about deinitialization in the gtk3 documentation. Is there any way to propperly deinitialize gtk or free the display in another way?
The solution was completely unrelated. I was setting the DISPLAY environment variable twice by accident. Apparently gtk can handle this but XOpenDisplay crashes.
I have added a test to only set it once, now everything works. Perhaps gtk does propperly deinitialize after gtk_main_quit()
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.
Using mixed managed/unmanaged C++ (Visual Studio 2008) I'm opening a windows form child window from a DirectX application. Weird stuff indeed, but it works, mostly. If I use showDialog() the child window works perfectly, but obviously the main app stops running (until the child is closed). If I use show() life is good, but the child has subtle issues. A textbox works and accepts input for example, but you can no longer use the Tab key to move to different controls. Mnemonics (Alt+hotkey) have stopped working as well.
I'm a huge keyboard shortcut fan, so this is very annoying. To make it worse, I'm not even sure how to Google this issue. Any help would be greatly appreciated.
To resolve the tabbing problem either use a separate thread to create the dialog and call showDialog(), or call IsDialogMessage in your main message loop.
My Qt 4.8 application runs on a Windows 7 touch screen. I'm not using the QTouchEvent capabilities. In this case and following the documentation, touch events should appear as normal mouse events. Unfortunately, this is not the case for all widgets.
The tabs of QTabWidgets can't be switch by touching them. It works via keyboard inputs. Other widgets work as the should (QPushButton, QLineEdit), interpreting the touch as mouse event.
The widgets are created using the Designer.
Despite the answer might not, my question is simple:
How can this happen, resp. how to fix this?
Thank's in advance...
Update:
Just figured out that it seems to be a compiler issue. Compiling With msvc2010 SP1 under Windows 8 causes the problem.
Compiling using WinXP and mingw results in a correct behavior.
Unfortunately, I would like to use MS Speech SDK, so I need Win7+ and msvc...
Update 2:
It's getting worse: Using a normal mouse everything reacts as aspected. But touching the screen is ignored. At least on the top half of the screen.
To be even more confusing: Using Qt 4.8 classic widgets does not react (QPushButtin, QLineEdit) but links in a QWebView react. Using Qt 5 it's vice versa.
You can find the application on source forge: httpplayer
http://sourceforge.net/projects/httpplayer/