Big Issue with Qt key inputs for gaming
-
Hi Chris,
My qt application is instantiated inside another mac application (Adoble Illustrator). This means I can not execute QApplication::exec() method right? I do have the need to poll the keyboard key state but if QApplication::exec() does not run, then keyPressEvent would never triggered. If so, the question is, is there a way to poll the keyboard using just the timer, without the keyPressEvent and keyReleaseEvent? Beside, keyPressEvent is only trigger when a QWidget is in focus, but in my case my QWidget is a subset of the Mac native application. Any idea? Please help.
-
Hi,
Please don't ressurect old threads. This question is unrelated.Qt probes for keyboard input in QWidget::nativeEvent() handlers which depend on an event loop. Basically anything comming from the OS(mouse, keyboard, resizes, focus etc.) is handled there as OSes work on a message delivery princibles.
If you're going to use widgets I can't imagine you wouldn't need an event loop. Connections, events and some internal Qt machinery rely on it. Look for topics about embedding Qt event loop into external app plugins. I've seen some in the past on this forum and the rest of the internet.
-
Thank you for splitting the thread.
Qt only has minimal support for embedding QApplication within a native application. In Qt 4.8, you use QMacNativeWidget (Mac) or QWinWidget (Windows) and not QWidget as wrapper for your UI components, otherwise you will get unstable event handling. In Qt 5, however, QWinWidget is no longer available which is unfortunate for, not as many, but still lots of people use Qt as embedded application to a native application.
With QMacNativeWidget, you don't create an event loop by QApplication::exec(), you still need to instantiate QApplication for QMacNativeWidget to work, because the native application already have an event loop. QMacNativeWidget works as long as QApplication::exec() is not used. Adding another event loop will cause problems associated with thread mis-synchronization.
So, Qt is helpless when it is used as embedded application, an area where Qt developers are not paying any attention to and probably will kill it in the near future like Qt 5 did with QWinWidget. So far from my experience, detecting keyboard event can not be done with Qt, since it depends on QApplication::exec() to start its own event loop, but by doing so, it messes up the main native application event loop causing events to get out of sync.
Am I right so far?
-
[quote author="vincentdoan" date="1396578297"]
My qt application is instantiated inside another mac application (Adoble Illustrator). This means I can not execute QApplication::exec(); method right?[/quote]Does it mean that Adobe Illustrator will spawn a new process?
Or it will start new thread and load your qt app as a shared library.You can use QEventLoop::processEvents() to process events.
-
QApplication is instantiated inside Illustrator without creating new process.
QEventLoop::processEvents() is available only if QApplication::exec() is used.
The reason QApplication::exec() can not be used is as described in my previous post. -
Hi,
QWinWidget was not part of Qt 4 but "Qt-Solutions":https://qt.gitorious.org/qt-solutions/qt-solutions You can clone it and build it with Qt 5
Hope it helps
-
Lots of Adobe Suite developers already tried to compile Qt 5 with QWinWidget source but it does not compatible.
Unless Qt developers have grudges against Windows, QWinWidget should have been in Qt along with QMacNativeWidget in the first place.
I still have not found a way to detect keyboard keys outside QWidget context, since I can not QApplication::exec(), the reason as mentioned above.
Can someone please tell me "Stop this nonsense, Qt was not meant to support users like you!", so I don't waist my time and your time?
-
What do you mean by not compatible ? If they have found a bug/regression build error, did they report it to the "bug report system":http://bugreports.qt-project.org ? If not it would be a good idea to, otherwise the Qt devs won't hear from it (unless it's talked about on e.g. the interest mailing list, but still a bug report would be best)
No grudges that I know of, as to why one is and the other is not, you would need to go back in the history of Qt.
I don't think it's nonsense, the classes are there to be used. However there might have been a change that broke something and it's important to fix it.
What I would recommend is: open a bug report (or several depending on your problems) with all infos needed (OS/Compilers etc.) and the errors you are getting.
