I am using Qt 4.8.3 on a small ARM embedded Linux device with a touchscreen. I have my touchscreen configured with tslib and calibrated it so there is a pointercal file in /etc/. The locations of my touch events work just fine but no matter what I get a QEvent for Mouse Move before Mouse Press or Mouse Release Events. Furthermore, I don't get any Mouse Related Events until I physically lift my finger from the touchscreen. I need normal behavior where I press on the touchscreen and receive a mouse down event immediately and then my move events ( if there are any ) and then a mouse release event when I lift my finger.
So what I'm seeing from the point of view of events received when I pressed down and then release looks like:
50 SockAct <-- Received right at press down
<-- NO Other events received until press released
<-- Now release by lifting finger from screen
50 SockAct <-- Immediately received a 50 ( SockAct ) and the rest of the events below:
2 <-- 2 == mouse down
2 <-- 2 == mouse down
3 <-- 3 == mouse release / up
3 <-- 3 == mouse release / up
77 <-- 77 == redraw
I also attempted to look at the QWS Server events by implementing the following qwsEventFilter to watch QWS events that come in to my QApplication:
/// For investigation mouse events
#include <QWSServer>
#include <QWSMouseHandler>
#include <QWSEvent>
bool GUIApp::qwsEventFilter(QWSEvent *e)
{
qDebug() << e->type;
if(e->type == QWSEvent::Mouse) {
QWSMouseHandler *curMouse = QWSServer::mouseHandler();
qDebug() << "mouse position is: " << curMouse->pos();
}
return false;
/*
QWSEvent::NoEvent 0 No event has occurred.
QWSEvent::Connected 1 An application has connected to the server.
QWSEvent::Mouse 2 A mouse button is pressed or released, or the mouse cursor is moved. See also Qt for Embedded Linux Pointer Handling.
*/
}
Now, when I launch my App I am seeing the same behavior after touching the screen -- that is the following is printed:
2 <-- Nothing is printed until I release my finger from the screen!
mouse position is: QPoint(89,312)
2
mouse position is: QPoint(89,312)
As you can see as soon as I release my finger I get 2 events, presumably press down and release.
I've run 'evtest' on my /dev/input/touchscreen device in Linux and certainly see a touch down event immediately when pressing down on the screen. And I do not get a mouse release event until I lift my finger, so the driver behaves as expected. There are also no 'repeat' touch down events when I press - it is just one event for one press down , but behaves correctly.
I'm not sure why I'm seeing the behavior I do. There must be a translation issue between Qt and the input device.
Furthermore, If I add a small 3ms delay in processing my MouseButtonRelease received event, then I get desired behavior in terms of how the app works but I still do not receive my Mouse events until I release the press. I should not have to add a delay at all, I would expect my mouse down to happen, then any moves, and finally a mouse up event in turn
Does anybody know how to fix this or what may be causing this?? Thank you very much!
--
I don't see the following printed out until I actually lift my finger:
...
MOVE TYPE: 5
"Mouse move (382,129)"
MOUSE BUTTON PRESS TYPE: 2
"Mouse Button Press (1)"
MOUSE BUTTON RELEASE TYPE: 3
"Mouse Button Release (1)"
....
Here is my eventFilter where I examine my received events in my App:
////////////////////////////////////////////////////////////////////////////////////////////////////////////
// Just for kicks print out the mouse position
if (event->type() == QEvent::MouseButtonPress)
{
qDebug() << "MOUSE BUTTON PRESS TYPE: " << event->type();
QMouseEvent *mouseEvent = static_cast<QMouseEvent*>(event);
qDebug() << QString("Mouse Button Press (%1)").arg(mouseEvent->button());
}
if (event->type() == QEvent::MouseMove)
{
qDebug() << "MOVE TYPE: " << event->type();
QMouseEvent *mouseEvent = static_cast<QMouseEvent*>(event);
qDebug() << QString("Mouse move (%1,%2)").arg(mouseEvent->globalX()).arg(mouseEvent->globalY());
}
if (event->type() == QEvent::MouseButtonRelease)
{
qDebug() << "MOUSE BUTTON RELEASE TYPE: " << event->type();
QMouseEvent *mouseEvent = static_cast<QMouseEvent*>(event);
delay();
qDebug() << QString("Mouse Button Release (%1)").arg(mouseEvent->button());
//return true; // Gobble the event
}
////////////////////////////////////////////////////////////////////////////////////////////////////////////
Here is my delay function:
void Monitor::delay()
{
QTime dieTime = QTime::currentTime().addMSecs(3);
while( QTime::currentTime() < dieTime )
QCoreApplication::processEvents(QEventLoop::AllEvents, 100);
}
Solved- I found this thread: https://github.com/kergoth/tslib/issues/10 which outlines the same problem. It seems to be an issue in Tslib with the Atmel MXT Maxtouch driver. Commenting out the Variance module in the ts.conf file solved my problem - I now get mouse down events immediately after touching the screen.
Related
I am trying to create a simple game in QT that uses event filter to catch keys pressed. It worked correctly until I implemented 'speed up' once space button is pressed. I have such a method in main window:
QSet<int> keysClicked; //declared in header
bool MainClass::eventFilter(QObject* target, QEvent* event)
{
if(event->type()==QEvent::KeyPress)
{
keysClicked.insert(static_cast<QKeyEvent*>(event)->key());
qDebug() << static_cast<QKeyEvent*>(event)->key();
}
else if(event->type()==QEvent::KeyRelease)
keysClicked.remove(static_cast<QKeyEvent*>(event)->key());
return QWidget::eventFilter(target, event);
}
and then a timer which sends keysClicked each n msecs to an object that we control.
keysClicked set should be able to contain all currently pressed keys.
And there is a problem, as it should contain spacebar, key_up, and either key_left or key_right:
It works correctly when I am holding spacebar, key_up and key_right
It doesn't work when I am holding spacebar, key_up and key_left (left key press is not found in eventFilter)
It works correctly when I am holding key_up and key_left
Could someone explain me what is the problem and how could I fix it? (point 2.)
I am creating an application that uses the tablet API for windows and so far I was able to capture the input of the stylus succesfully. I am able to handle the movement, stylus down and up events and pressure. What I am still missing is the ability to identify the barrel button pressed. While I am capturing the StylusButtonDown event, this is fired also when the stylus is down on the tablet.
For reference here is my (ideal) implementation:
STDMETHOD(StylusButtonDown)(IRealTimeStylus* rts, STYLUS_ID id, const GUID* guid, POINT* pt)
{
if (BARREL_BUTTON_ID == *guid) {
s_buttonDown = true;
// DEBUG
std::cout << "[StylusButtonDown]" << std::endl;
// DEBUG
}
return S_OK;
}
The problem I have is to fill in the BARREL_BUTTON_ID constant. Any expert with an idea?
Thanks a lot!
I'm writing a Game Engine just for practice but I still stuck with the first chellange. The Window Manager.
https://github.com/thebenius/SDL
I've created a GitHub Repo to show you the code but don't worry. Its not much. But I absolutely don't know where is my mistake.
In the Code I create three Windows and I Manage the input for SDL_QUIT to stop the game loop and for SDL_WINDOWEVENT_CLOSE to close the windows.
Everything works fine until the last window is closed. As far as I know, now the SDL_QUIT Event must be emitted by SDL. But the Gameloop goes on.
I think I maybe have a kind of memory leak and there is still a windows saved. But I checked the window stack (Window::windows hashmap) it is empty. And also the variables in main are cleared.
I also tried to additionally clear the window and renderer variable in the hash map
Window::~Window() {
// Delete Window and Renderer
SDL_DestroyRenderer(Window::windows[this->windowID]->renderer);
SDL_DestroyWindow(Window::windows[this->windowID]->window);
Window::windows[this->windowID]->renderer = nullptr;
Window::windows[this->windowID]->window = nullptr;
// Delete Window from map
Window::windows.erase(this->windowID);
// Delete Window and Renderer
SDL_DestroyRenderer(this->renderer);
SDL_DestroyWindow(this->window);
// Reset Pointer
this->renderer = nullptr;
this->window = nullptr;
Nothing worked.
I'm new in C++ and SDL. I hope you can help me out.
Thank you o11c,
Your answer was the riddles solution.
I just put SDL_Quit() out of the Destructor. This obviously blocked the Event Handler to catch SDL_QUIT. So I put it to the constructor in atexit()
After that (don't know why before not) I got an Segfault when deleting the window pointer in main. I deleted that and just set them all to nullptr.
Now the WindowManager works properly. Thank you for your help
I think SDL_QUIT is only an hook called if you call SDL_Quit(), to give the user the opportunity to do some quit stuff, the manual:
You should call this function even if you have already shutdown each initialized subsystem with SDL_QuitSubSystem(). It is safe to call this function even in the case of errors in initialization
You can use this function with atexit() to ensure that it is run when your application is shutdown, but it is not wise to do this from a library or other dynamically loaded code
To catch a window close event see SDL_WindowEvent, SDL_WINDOWEVENT and SDL_WINDOWEVENT_CLOSE, the id of the closing window is given as argument.
* \file SDL_quit.h
*
* An ::SDL_QUIT event is generated when the user tries to close the application
* window. If it is ignored or filtered out, the window will remain open.
* If it is not ignored or filtered, it is queued normally and the window
* is allowed to close. When the window is closed, screen updates will
* complete, but have no effect.
*
* SDL_Init() installs signal handlers for SIGINT (keyboard interrupt)
* and SIGTERM (system termination request), if handlers do not already
* exist, that generate ::SDL_QUIT events as well. There is no way
* to determine the cause of an ::SDL_QUIT event, but setting a signal
* handler in your application will override the default generation of
* quit events for that signal.
*
* \sa SDL_Quit()
SDL_EventType#SDL_QUIT
An SDL_QUIT event is generated when the user clicks on the close button of the last existing window.
You shouldn't call SDL_Quit() in the destructor, but only once before leaving the application (is suggested to use it with atexit())
--- a/main.cpp
+++ b/main.cpp
## -32,17 +32,18 ## int main() {
}
-
// Delete Windows
- delete window;
- delete window2;
- delete window3;
+ // delete window;
+ // delete window2;
+ // delete window3;
// reset pointer
window = nullptr;
window2 = nullptr;
window3 = nullptr;
+ SDL_Quit();
+
// Close Program properly
return 0;
}
--- a/video/window.cpp
+++ b/video/window.cpp
## -51,7 +51,7 ## Window::~Window() {
// Shutdown if last window closed
if(this->windows.empty()) {
// Shutdown Video System
- SDL_Quit();
+ // SDL_Quit();
std::cout << "shuted down Video" << std::endl;
}
}
I'm trying to add GUI for easier level editing in our game engine. We're using SFML for all the basic stuff (window management, input events etc). I've chosen AntTweakBar because it is a well known library with a few examples around. I was following the tutorial at AntTweakBar's website
I was able to draw a simple bar with those example codes. However, mouse events received by SFML are not registered by AntTweakBar's TwEventSDL()function. Here is an example code for Input:
sf::Event event;
while (_pWindow->pollEvent(event))
{
// Check if the event should be handled by AntTweakBar
int handled = TwEventSFML(&event, 2, 3); // for SFML version 2.3
if (!handled){
switch (event.type)
{
case sf::Event::MouseButtonPressed: // To check whether SFML received mouse button events properly
if (event.mouseButton.button == sf::Mouse::Button::Left){
std::cout << "Left button pressed" << std::endl;
std::cout << "x: " << event.mouseButton.x << std::endl;
std::cout << "y: " << event.mouseButton.y << std::endl;
}
}
}
else{ //To check whether TwEventSFML received events
std::cout << "FINALLY!" << std::endl;
}
When I press buttons, I can see "FINALLY!" showing up. I can also see that my mouse clicks are received by SFML. However, when I click on an AntTweakBar element (be it a button or help section) it doesn't register it. (Also, I can't see "FINALLY!" when I use the mouse).
Any help or ideas will be appreciated.
Anttweakbar hasnt been updated in 3 years, last SFML integration was for SFML 1.6
What version of SFML are you using ?
If not 1.6 then you have to create your own input handler for it.
In a particular situation I need my command line based C++ application to launch a quick dialog using gtkmm 2.4. I could really use some direction here.
I tried launching the dialog as a standalone without initializing the top level window:
Gtk::Main kit( NULL,NULL );
Gtk::Window toplevel;
MyApp::myDialog d(toplevel);
int result = d.run();
This created my dialog but it doesn't close when the ok or cancel button is hit and none of quit/delete/hide api calls I could find could get rid of it. It only goes away when the program exits (even if it is created in a method which exits earlier). I'm guessing this is in part because it needs an active main window to handle some of its lifetime/visibility management. If I could make it respond normally to the ok/cancel buttons I would be all set!
Next I tried creating and launching the main window properly and launching the dialog from within the constructor of the main window. (It takes the Gtk::Main as an argument so I could try killing that directly.)
class cprompt : public Gtk::Window
{
public:
cprompt(Gtk::Main* prompt){
MyApp::myDialog* d = new MyApp::myDialog (*this);
std::cout << "ABOUT TO RUN DIALOG" << std::endl;
int result = d->run();
std::cout << "RAN DIALOG" << std::endl;
d->hide();
delete d;
std::cout << "CALLING QUIT" << std::endl;
this->hide();
Gtk::Main::quit();
prompt->quit();
//None of the above calls do anything. The empty 'top level' window hangs around and blocks until manually closed.
std::cout << "CALLED QUIT" << std::endl;
};
virtual ~cprompt(){};
};
Now the dialog works as expected, but the main window pops up after the dialog is closed (an empty gray square with an exit button) and I can't find a way to hide or exit it outside of clicking the exit button. All the calls I make to close it or quit the gtk loop automatically are inside the constructor so I'm guessing they aren't valid at that point. If I could make the whole operation shut down after the dialog returns in the window constructor, again I would be all set.
My next approach is going to be to use the top level window itself as the dialog, but I was hoping to avoid this because the dialog I need is already provided by another library and I'll have to re-implement the ui from scratch if I can't launch the dialog straight up.
Had the same problem with Gtk. To fix it, I neeeded to manually close the window and then do the gtk loop iterations. My code looks like this (for a filechooser_dialog) :
gint result = gtk_dialog_run(GTK_DIALOG(m_fileDialog));
if(result == GTK_RESPONSE_ACCEPT)
{
char* filename = gtk_file_chooser_get_filename(GTK_FILE_CHOOSER(m_fileDialog));
m_selectedFileName = std::string(filename);
g_free(filename);
}
gtk_window_close(GTK_WINDOW(m_fileDialog)); //Close the dialog manually
while (gtk_events_pending()) //until there are no more events :
gtk_main_iteration_do(false); //process the main iteration