I should trigger all events in my Qt/Qml application. In particular I'm trying to trigger key and mouse events. I would to implement a sort of standby with a QTimer that reset when the event is triggered.
Is possible to implement this feature in my Qt/Qml application?
impossible to trigger events from all of these widgets (using
onClicked() signal for example)
Why not? Every application has multiple "widgets" and it is done using the signal handler hooks in almost all of the cases with some very, and I do mean very rare exceptions.
Thus I should trigger a general events on QApplication to know if
mouse or keyboard buttons has been clicked
And from there on use some personal method of determining what that event should do? That sounds like a very bad idea if your application is indeed as diverse in GUI elements as you claim. I highly doubt it will be easier to create a more robust or efficient solution than the one that is already implemented, or a less buggy for that matter.
Either you are completely new to QML and its programming paradigm, and haven't realized that handler hooks are the intended way to do user interaction, which is the more likely case, or you are trying to do something very "custom".
It is not all that hard to implement a "global" handler for keyboard and mouse events, just put a single MouseArea on top of your application window and use that to capture all mouse interaction, and have keyboard focus set on a single item that acts as a keyboard event receiver.
However this means that once you do that, you take full responsibility of manually managing the way events are directed. I've done this for keyboard events, because QML's "one focus item" design didn't suit my particular needs, and I can tell you that it is a hassle. Doing it for the mouse too will only make it even harder and more bug prone.
It also means you have to give up on pretty much all UI elements QML provides out of the box, since they all rely on receiving actual focus and events.
Of course, you could intercept events at an even lower level from C++, but that will only be even harder and more prone to actually breaking stuff.
Considering your sparse activity history, It does look like what you really need to be doing is familiarizing yourself better with the programming paradigm behind QML than asking questions about things you don't need to do and really don't want to be doing, because they are complex and unnecessary and in most use cases represent anti-patterns that are very counterproductive.
Related
So when I use a setText() on a QLabel for example, Qt automatically updates the view/gui for me and the new text is shown, but what happens behind the scenes? Is there an update function that gets called automatically when using functions like setText()?
Thanks!!
You should check the basic documentation in this link.
The internal system is a little bit more complex but in general, it follows the observer pattern. This mechanism allows the detection of a user action or changing state, and respond to this action.
Low-level interactions, like refreshing the screen are implemented via the Event System
In Qt, events are objects, derived from the abstract QEvent class, that represent things that have happened either within an application or as a result of outside activity that the application needs to know about. Events can be received and handled by any instance of a QObject subclass, but they are especially relevant to widgets. This document describes how events are delivered and handled in a typical application.
So, regarding the display process, there is a dedicated event. A QWidget object handles/subscribe to a PaintEvent, see QWidget::paintEvent.
This event handler can be reimplemented in a subclass to receive paint events passed in event. A paint event is a request to repaint all or part of a widget.
When you call, QLineEdit::setText(), the widget will be repainted the next time a display event is triggered, based in the OS configuration, refresh rate, etc.
For high-level interactions, Qt uses a similar pattern based in the signal/slot mechanism:
Observer pattern is used everywhere in GUI applications and often leads to some boilerplate code. Qt was created with the idea of removing this boilerplate code and providing a nice and clean syntax, and the signal and slots mechanism is the answer.
I am interested to port applications that use a mouse based interface to a touchscreen based interface and I wonder how to best avoid mis-moves when a user with "large and wiggly" fingertips uses my applications
If the user touches a certain location and his/her/its pulse or impatience causes the fingertip to wiggle around some pixels, my application should not interpret this as a QEvent::MouseMove and cause scrolling of e.g. a list underneath.
There seem to be two classes that do press-like events, namely QTouchEvent and QMouseEvent.
What is the difference in respect to the above issue with reliably detecting the users intent? Does QTouchEvent solve that issue for me?
Do I need to add event handlers for QTouchEvent, in parallel to QMouseEvent (in order to provide backward compatibility with mouse users)?
I imagine that it would not be a good idea to implement this sort of tolerance in every widget again, but there should be some global instance that makes this work, in e.g. QApplication or X11 directly.
Try using QApplication::startDragDistance(). This is application wide accessible. If this only needs to be checked in one part of your application (e.g. small sized elements in a list), you can still use a self defined distance. Then just reimplement QWidget::mouseMoveEvent(QMouseEvent *event) and include (from the docs):
if ((startPos - currentPos).manhattanLength() >= QApplication::startDragDistance())
startTheDrag();
I'm making a game GUI and basically each Widget can have other widgets which listen to mouse or keyboard events. Anyone of these can consume the event too (and then any subsequent ones will not receive it.
The part I'm unsure for is if the order shoud be:
Send event to Target Widget
if(event is not consumed)
{
Send each listener the event
}
or
Send each listener the event
if(event is not consumed)
{
Send event to Target Widget
}
Which one makes most sense?
Thanks
The best event model I've every used is from the Tk toolkit (and I've used perhaps a dozen toolkits professionally during my career). The naive description is that the event starts from the most specific (the actual widget in which the widget occured) up a chain to the least specific (a global binding).
It's a little more complex than that, but that's the general idea, and it works extremely well. At each step in the process from most specific to most generic, each handler has the opportunity to say "I've handled this event" and to stop it from propagating. Or, it can handle or ignore the error while also letting it percolate up.
If you're rolling your own event mechanism you owe it to yourself to study Tk's "bindtag" mechanism. The default behavior is as I described, but the bindtag mechanism is much more powerful because it lets you alter the order for each widget. I've found this invaluable because, while the standard behavior works in 95% of the cases, you want to be able to support that other 5%.
I would probably use the first. It makes more logical sense to me (at least) to not send the event out unless it's not wanted.
I mean, you wouldn't send out invitations (event) to your friends (the listeners) if you cancelled the party (the original event has been consumed).
How to know if a mouse click is simulated or not? When mouse click send by a program or real mouse device
... I'm programming a system detection for a game to avoid bots, autoclicks,etc that only accept legit mouse clicks
This depends a bit on the kind of application you are writing, but if you can, I would watch the cursor movement, not the clicks.
Human mouse movement has non-uniform speeds, reaction times, imprecisions (clicks on different coordinates of your buttons, etc...).
Also, you can defend a gui against bots by randomly requiring an interaction that is hard to script. For example: If scripts depend upon buttons being always in the same position, I would make sure that, while trying to remain intuitive, the dialog should pop up in slightly different positions every time.
Otherwise: There is no way to detect if the mouse is a real one or a really well simulated one. The Windows HID/MacOS/Linux driver layer abstracts away the distinction between Mice, TrackPens, TrackBalls, draw-pads, touch screens... and of course script-mice...
Although the blog post itself is about a different issue, I refer you to Raymond Chen's excellent Old New Thing. In this specific blog post he talks about the validity of message parameters going into an application, but also makes the point that:
There's no point discussing the possibility that the sender of the message is playing tricks and lying to you because (1) your program should just go along with the ruse and respond to fake menu messages as if they were real menu messages, because (2) there's no way to tell that you're being lied to anyway. To detect lying, you'd have to be able to read into the mindset of the programmer who sent you the message.
Essentially the argument is that you should respond to mouse clicks as mouse clicks, regardless of how those clicks were generated.
Is mouse keys simulated mouse input or legit? The point of simulating mouse input is to make them look exactly like real mouse input. If the simulation is doing its job, then your job is impossible. Sorry, that's the blessing & curse of software for you. Here are some more imperfect ideas:
Use GetKeyboardState and verify that the button states are correct. If the message faker is using PostMessage, they will likely not be setting keyboard state and this would indicate fakery.
If you are targeting known applications that are doing the input simulation, detect them and complain. This is not perfect at all for many reasons.
Fuzzy logic, as many other people have suggested.
You need to be creative and figure out the difference between a simulated event and a real one to you, as there is no generalized answer.
It can't be done (reliably (with software alone anyway))
I've used WIN32API calls to read pixels/manipulate the mouse/send keystrokes to automate large portions of video games and other repetitive tasks. You could write a lot of code to analyze the input, but equally smart developers are just going to modify their code to match.
When I first try to automate a mouse click, that's all I'll do. Send a mouse click. And most of the time it works. You might have code that tracks the mouse movement and the entire stack of mouse events that would fire along with a legitimate click and say, 'That wasn't real - we ignore it' but nothing stops the developer from also implementing mouse movements.
The mouse events are more complex than keypresses; but it's essentially the same idea. If you write code that monitors the time between keypresses and determine that I'm sending the '2' key to your application in EXACTLY 250ms intervals, you might decide I'm a bot. But, all I'll do is modify my code to send the keystroke in 250ms + a random value between -25 and 25 ms.
It's a never-ending game of cat and mouse. The best solution is to make tasks non-trivial so simple forms of automation aren't applicable.
The question is a bit thin on details.
Events can be sent directly to controls without moving the mouse so find out where the mouse is when you get the click event and see if it's on the control. Keyboard input requires control focus, so check that too.
For situations where the mouse moves, you won't be able to tell if the mouse movement is recorded and played back. If its scripted then perhaps you could monitor the mouse behavior in the parent panel(s) of the control and use those events and movements to ascertain whether it is real or not. An automated click might appear from nowhere and cause an flurry of unlikely hover, focus events.
Only way it would be possible is with some specialist hardware and software on the mouse itself that sends evidence of the actual mechanical click. Via software this is not possible.
Although in my other answer I mention that you should ideally just respond to clicks as clicks, there is one possibility that could work, depending on how a "programmatic" click is generated.
I am assuming a Windows platform, due to the "vb.net" tag:
With the WinAPI you can send a message to any window in order to simulate, for example, a WM_LBUTTONDOWN event. In this message you would include the X and Y location of the mouse at the time the button was pressed - or where the receiving program expects it to be. When you handle the message you could use the GetCursorPos call to get the actual cursor position. Verify that the current position is close to that in the message, and handle it as a click, otherwise ignore it.
Bear in mind however that the nature of the message queue is such that it could take some time to handle the event, and the mouse can move a long way in a short space of time.
This solution would only work if the "click" is generated by a simple Send/PostMessage. If the application that is generating the click simulates the movement of the mouse also, then you should probably see the other answers :)
You can check the mouse event flags LLMHF_INJECTED and LLMHF_LOWER_IL_INJECTED or utilize input hooks to monitor mouse input data, where malformed data may indicated that input was injected.
https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-msllhookstruct
https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexa
I'm not sure there is a way to determine with perfect accuracy whether a mouse click is automated or not. I mean, you could write your own USB driver that sits in between the native mouse driver and the OS and relays only "real" clicks to you. However, even that can be defeated by plugging in a USB device (like a smartphone) that's programmed to send USB packets to host computer.
What are you trying to accomplish that requires you to distinguish between real mouse clicks and fake ones?
Create a statistical learning solution by logging the past X mouse events in your program. When the user clicks on the control, determine the probability based on the last X actions that it's a real click.
Train your solution using real clicks and a large variety of automated scenarios.
This is obviously not a guaranteed-to-work solution and is more for fun than anything else.
It is much more harder than what you think because input macro programs produce legit mouse and keyboard input messages to your game. I don't think there is a way to check if the input message is actually triggered by a physical hardware input (like mouse or keyboard) unless OS provides you with accessibility of input-driver-level.
Since this is specifically for a game, you can see how other games handle this situation. Some of the common methods are,
Check frequency of mouse clicks. (human beings cannot click as fast as programs.)
At random points or when it doubts, use CAPTCHA to verify. (Read this: http://www.threadmeters.com/v-1Vvd/CAPTCHA_The_Obvious_AntiBot_Solution/ )
Use outside monitoring tools to inspect all processes running in a machine to find out programs known for cheating purpose. Steam does this. Check Valve Anti-Cheat System Blizzard's WoW also does the same thing with Warden.
My own advice would be "Use your gameplay system". Since every game has its own rules and gameplay styles, it wouldn't be too hard to detect whether a player is cheating or not. This approach won't be a general solution and it could be silly but if it works for your game, why not? :)
There are two ways you could work around this problem.
Make a new Button with a Text proving that the user isn't AFK and if the user doesn't press the button, kick him or her out. Generate the button in random locations.
If the user isn't moving for a while, (for example, 10 mins) kick him or her out.
In the Qt world, what is the difference of events and signal/slots?
Does one replace the other? Are events an abstraction of signal/slots?
In Qt, signals and events are both implementations of the Observer pattern. They are used in different situations because they have different strengths and weaknesses.
First of all let's define what we mean by 'Qt event' exactly: a virtual function in a Qt class, which you're expected to reimplement in a base class of yours if you want to handle the event. It's related to the Template Method pattern.
Note how I used the word "handle". Indeed, here's a basic difference between the intent of signals and events:
You "handle" events
You "get notified of" signal emissions
The difference is that when you "handle" the event, you take on the responsibility to "respond" with a behavior that is useful outside the class. For example, consider an app that has a button with a number on it. The app needs to let the user focus the button and change the number by pressing the "up" and "down" keyboard keys. Otherwise the button should function like a normal QPushButton (it can be clicked, etc). In Qt this is done by creating your own little reusable "component" (subclass of QPushButton), which reimplements QWidget::keyPressEvent. Pseudocode:
class NumericButton extends QPushButton
private void addToNumber(int value):
// ...
reimplement base.keyPressEvent(QKeyEvent event):
if(event.key == up)
this.addToNumber(1)
else if(event.key == down)
this.addToNumber(-1)
else
base.keyPressEvent(event)
See? This code presents a new abstraction: a widget that acts like a button, but with some extra functionality. We added this functionality very conveniently:
Since we reimplemented a virtual, our implementation automatically became encapsulated in our class. If Qt's designers had made keyPressEvent a signal, we would need to decide whether to inherit QPushButton or just externally connect to the signal. But that would be stupid, since in Qt you're always expected to inherit when writing a widget with a custom behavior (for good reason - reusability/modularity). So by making keyPressEvent an event, they convey their intent that keyPressEvent is just a basic building block of functionality. If it were a signal, it'd look like a user-facing thing, when it's not intended to be.
Since the base-class-implementation of the function is available, we easily implement the Chain-of-responsibility pattern by handling our special cases (up&down keys) and leaving the rest to the base class. You can see this would be nearly impossible if keyPressEvent were a signal.
The design of Qt is well thought out - they made us fall into the pit of success by making it easy to do the right thing and hard to do the wrong thing (by making keyPressEvent an event).
On the other hand, consider the simplest usage of QPushButton - just instantiating it and getting notified when it's clicked:
button = new QPushButton(this)
connect(button, SIGNAL(clicked()), SLOT(sayHello())
This is clearly meant to be done by the user of the class:
if we had to subclass QPushButton every time we want some button to notify us of a click, that would require a lot of subclasses for no good reason! A widget that always shows a "Hello world" messagebox when clicked is useful only in a single case - so it's totally not reusable. Again, we have no choice but to do the right thing - by connecting to it externally.
we may want to connect several slots to clicked() - or connect several signals to sayHello(). With signals there is no fuss. With subclassing you would have to sit down and ponder some class diagrams until you decide on an appropriate design.
Note that one of the places QPushButton emits clicked() is in its mousePressEvent() implementation. That doesn't mean clicked() and mousePressEvent() are interchangable - just that they're related.
So signals and events have different purposes (but are related in that both let you "subscribe" to a notification of something happening).
I don’t like the answers so far. – Let me concentrate on this part of the question:
Are events an abstraction of signal/slots?
Short answer: no. The long answer raises a “better” question: How are signals and events related?
An idle main loop (Qt’s for example) is usually “stuck” in a select() call of the operating system. That call makes the application “sleep”, while it passes a bunch of sockets or files or whatever to the kernel asking for: if something changes on these, let the select() call return. – And the kernel, as the master of the world, knows when that happens.
The result of that select() call could be: new data on the socket connect to X11, a packet to a UDP port we listen on came in, etc. – That stuff is neither a Qt signal, nor a Qt event, and the Qt main loop decides itself if it turns the fresh data into the one, the other or ignores it.
Qt could call a method (or several) like keyPressEvent(), effectively turning it into a Qt event. Or Qt emits a signal, which in effect looks up all functions registered for that signal, and calls them one after the other.
One difference of those two concepts is visible here: a slot has no vote on whether other slots registered to that signal will get called or not. – Events are more like a chain, and the event handler decides if it interrupts that chain or not. Signals look like a star or tree in this respect.
An event can trigger or be entirely turned into a signal (just emit one, and don’t call “super()”). A signal can be turned into an event (call an event handler).
What abstracts what depends on the case: the clicked()-signal abstracts mouse events (a button goes down and up again without too much moving around). Keyboard events are abstractions from lower levels (things like 果 or é are several key strokes on my system).
Maybe the focusInEvent() is an example of the opposite: it could use (and thus abstract) the clicked() signal, but I don’t know if it actually does.
The Qt documentation probably explains it best:
In Qt, events are objects, derived
from the abstract QEvent class, that
represent things that have happened
either within an application or as a
result of outside activity that the
application needs to know about.
Events can be received and handled by
any instance of a QObject subclass,
but they are especially relevant to
widgets. This document describes how
events are delivered and handled in a
typical application.
So events and signal/slots are two parallel mechanisms accomplishing the same things. In general, an event will be generated by an outside entity (for example, keyboard or mouse wheel) and will be delivered through the event loop in QApplication. In general, unless you set up the code, you will not be generating events. You might filter them through QObject::installEventFilter() or handle events in subclassed object by overriding the appropriate functions.
Signals and Slots are much easier to generate and receive and you can connect any two QObject subclasses. They are handled through the Metaclass (have a look at your moc_classname.cpp file for more), but most of the interclass communication that you will produce will probably use signals and slots. Signals can get delivered immediately or deferred via a queue (if you are using threads).
A signal can be generated.
Events are dispatched by the event loop. Each GUI program needs an event loop, whatever you write it Windows or Linux, using Qt, Win32 or any other GUI library. As well each thread has its own event loop. In Qt "GUI Event Loop" (which is the main loop of all Qt applications) is hidden, but you start it calling:
QApplication a(argc, argv);
return a.exec();
Messages OS and other applications send to your program are dispatched as events.
Signals and slots are Qt mechanisms. In the process of compilations using moc (meta-object compiler), they are changed to callback functions.
Event should have one receiver, which should dispatch it. No one else should get that event.
All slots connected to the emitted signal will be executed.
You shouldn't think of Signals as events, because as you can read in the Qt documentation:
When a signal is emitted, the slots connected to it are usually executed immediately, just like a normal function call. When this happens, the signals and
slots mechanism is totally independent
of any GUI event loop.
When you send an event, it must wait for some time until the event loop dispatches all events that came earlier. Because of this, execution of the code after sending event or signal is different. Code following sending an event will be run immediately. With the signals and slots mechanisms it depends on the connection type. Normally it will be executed after all slots. Using Qt::QueuedConnection, it will be executed immediately, just like events. Check all connection types in the Qt documentation.
There is an article that discusses event processing in some detail: http://www.packtpub.com/article/events-and-signals
It discussions the difference between events and signals here:
Events and signals are two parallel mechanisms used to accomplish the
same thing. As a general difference, signals are useful when using a
widget, whereas events are useful when implementing the widget. For
example, when we are using a widget like QPushButton, we are more
interested in its clicked() signal than in the low-level mouse press
or key press events that caused the signal to be emitted. But if we
are implementing the QPushButton class, we are more interested in the
implementation of code for mouse and key events. Also, we usually
handle events but get notified by signal emissions.
This seems to be a common way of talking about it, as the accepted answer uses some of the same phrases.
Note, please see helpful comments below on this answer from Kuba Ober, that make me wonder if it might be a bit simplistic.
TL;DR: Signals and slots are indirect method calls. Events are data structures. So they are quite different animals.
The only time when they come together is when slot calls are made across thread boundaries. The slot call arguments are packed up in a data structure and get sent as an event to the receiving thread's event queue. In the receiving thread, the QObject::event method unpacks the arguments, executes the call, and possibly returns the result if it was a blocking connection.
If we're willing to generalize to oblivion, one could think of events as as a way of invoking the target object's event method. This is an indirect method call, after a fashion - but I don't think it's a helpful way of thinking about it, even if it's a true statement.
'Event processing' by Leow Wee Kheng says:
Jasmine Blanchette says:
The main reason why you would use events rather than standard function calls, or signals and slots, is that events can be used both synchronously and asynchronously (depending on whether you call sendEvent() or postEvents()), whereas calling a function or invoking a slot is always synchronous. Another advantage of events is that they can be filtered.
Events (in a general sense of user/network interaction) are typically handled in Qt with signals/slots, but signals/slots can do plenty of other things.
QEvent and its subclasses are basically just little standardized data packages for the framework to communicate with your code. If you want to pay attention to the mouse in some way, you only have to look at the QMouseEvent API, and the library designers don't have to reinvent the wheel every time you need to figure out what the mouse did in some corner of the Qt API.
It is true that if you're waiting for events (again in the general case) of some sort, your slot will almost certainly accept a QEvent subclass as an argument.
With that said, signals and slots can certainly be used without QEvents, although you'll find that the original impetus for activating a signal will often be some kind of user interaction or other asynchronous activity. Sometimes, however, your code will just reach a point where firing off a certain signal will be the right thing to do. For example, firing off a signal connected to a progress bar during a long process doesn't involve a QEvent up to that point.
Another minor pragmatic consideration: emitting or receiving signals requires inheriting QObject whereas an object of any inheritance can post or send an event (since you invoke QCoreApplication.sendEvent() or postEvent()) This is usually not an issue but: to use signals PyQt strangely requires QObject to be the first super class, and you might not want to rearrange your inheritance order just to be able to send signals.)
In my opinion events are completely redundant and could be thrown out. There is no reason why signals could not be replaced by events or events by signals, except that Qt is already set up as it is. Queued signals are wrapped by events and events could conceivably be wrapped by signals, for example:
connect(this, &MyItem::mouseMove, [this](QMouseEvent*){});
Would replace the convenience mouseMoveEvent() function found in QWidget (but not in QQuickItem anymore) and would handle mouseMove signals that a scene manager would emit for the item. The fact that the signal is emitted on behalf of the item by some outside entity is unimportant and happens quite often in the world of Qt components, even though it is supposedly not allowed (Qt components often circumvent this rule). But Qt is a conglomerate of many different design decisions and pretty much cast in stone for fear of breaking old code (which happens often enough anyway).