I have a QAbstractItemView that needs to react to single and double click events. The actions are different depending on whether it was single clicked or double clicked. The problem that is occurring is that the single click event is received prior to the double click event.
Is there a recommended way/best practice for distinguishing between the two? I don't want to perform the single click action when the user has actually double clicked.
I am using Qt 4.6
It's a good UI design to make sure your single-clicks and double-clicks are conceptually related:
Single-Click: select icon
Double-Click: select icon and open it
Single-Click: select color
Double-Click: select color and open palette editor
Notice how in these examples the single-click action is actually a subset of the double-click. This means you can go ahead and do your single-click action normally and just do the additional action if the double-click comes in.
If your user interface does something like:
Single-Click: select icon
Double-Click: close window
Then you are setting your users up to fail. Even if they remember what single-clicking does versus double-clicking all the time, it's very easy to accidentally move your mouse too far while double-clicking or wait too long.
Edit:
I'm sorry to hear that.
In that case, I found these two articles useful:
Logical consequences of the way
Windows converts single-clicks into
double-clicks
Implementing
higher-order clicks
You can find answer in the thread titled Double Click Capturing on QtCentre forum;
You could have a timer. Start the
timer in the releaseEvent handler and
make sure the timeout is long enough
to handle the double click first.
Then, in the double click event
handler you can stop the timer and
prevent it from firing. If a double
click handler is not triggered, the
timer will timeout and call a slot of
your choice, where you can handle the
single click. This is of course a
nasty hack, but has a chance to work.
wysota
Using PySide which is the Python binding of Qt 4.8 I saw that single clicks deliver a QEvent.MouseButtonPress event and double clicks deliver a single QEvent.MouseButtonPress event closely followed by a QEvent.MouseButtonDblClick. The delay is approximately about 100ms on Windows. That means you still have a problem if you need to differentiate between single and double clicks.
The solution needs another QTimer with a slightly higher delay than the inbuilt delay (adding some overhead). If you observe a QEvent.MouseButtonPress event you start your own timer, in case of timeout it is a single click. In case of a QEvent.MouseButtonDblClick it is a double click and you stop the timer to avoid counting as single click.
Related
Ctrl+Escape is a global Windows shortcut for opening main system menu. But I would like my Qt application to use this shortcut without triggering Windows main menu. I know it is probably a bad idea to override system shortcuts in general, but I would like to use this shortcut is a very limited use case.
This usecase is as follows. I have a popup window containing several rows or items. This window is opened by Ctrl+Tab and while the user holds Ctrl and keep pressing Tab, the current rows are cycled through. When the user releases Ctrl, the current row is used for some operation... But sometimes it happens that user presses Ctrl+Tab and then realizes he does not want to continue. He usually presses Escape while still holding Ctrl. And then it triggers Windows system menu and normal user gets confused, choleric user get angry... which is a bad thing. In other words I would like to be able to close the popup window when user presses Ctrl+Escape. How to do that? It is even possible?
If I write the code using this shortcut like any other short, it does not work and it always triggers Windows main menu.
As I understand it, Qt will typically not receive the key event if the underlying window system has intercepted it. For example even QtCreator cannot override system-wide shortcuts.
This question is almost a duplicate of: C++/Qt Global Hotkeys
While that question is asking specifically to capture shortcuts in a hidden/background application, I think the basic concept is the same -- capture shortcuts before the window system processes them.
From that answer, UGlobalHotkey seems pretty good, and the How to use System-Wide Hotkeys in your Qt application blog post could be useful for your limited-use case (but read the comments on that blog post about fixing the example).
Also found:
https://github.com/mitei/qglobalshortcut
https://github.com/Skycoder42/QHotkey (looks like a more detailed version of above)
What I'm trying to do:
I have a Python(PySide) and Qt/QML UI that today responds to keyboard input (actually it's an IR remote control, but the input events are received as though they were coming from a keyboard).
I want to be able to also respond to mouse events. So where today the user uses arrow keys to navigate to a particular button and presses OK (i.e., Return) to activate the handling for that button, I would like them to just be able to click the mouse on that button and get the same handling behavior.
What I have so far:
I've already got Keys.onReturnPressed: handling in my QML code that does what I need to do when the user presses OK/Return. And I've added MouseArea { ... onClicked: {...} ... } QML code that recognizes when I click on a given control. So I already see in my log when the mouse click events occur.
My question:
How do I tie them together? I want to make the onClicked: behavior just generate some kind of event (a signal, maybe?) that causes the onReturnPressed: handling to be invoked. (I'm not at all averse to passing events through the Python side of things if that's what it takes to make this work.)
(I guess I should mention here that the existing code includes some base classes (is that the right terminology here?) that can define behavior across ALL controls of a certain type (e.g., Buttons) in the system. So while each of the many, many Buttons has its own onReturnPressed: code providing its unique handling, my objective is to have a single onClicked: handler in the base class that makes all Buttons respond to clicks as they do to Return presses today.)
Can anyone point me in the right direction?
BTW: Yes, I'm aware that there's a second problem here, too, of navigation. That is, even once I've turned the mouse click into a press
of the Return key, I still have to solve the problem of associating it
with the right control on the screen.
I sort of didn't want to muddy the waters by asking too many things at once.
I'll get to that one
when I've got this one in hand. (...unless you've got a simple solution already up your sleeve... In that case I'm all ears.)
I'm trying to catch single clicks and double clicks on my figure.
As stated in another answer, the event contains event.dblclick which is False or True, at least in Version 1.4.2, so double clicks can be got.
The only problem is that it's not easy to distinguish between a single click and a double click because when double-clicking the event gets fired twice. The first time it's with event.dblclick=False and the second time it's with event.dblclick=True.
Is there any solution to this? I saw that the same problem regarding qt is discussed here.
You need a software debouncer.
Basically, you start a timer on the 1st click. If the timer runs out, then you proceed to process the single-click event. If a 2nd click is detected within the timer, process a double-click event.
This can actually be expanded to n-clicks if needed. I've found some uses for triple-click events.
Here is one implemented in wxPython. Should be relatively easy to port to matplotlib.
Also, if you're on Windows, I would recommend using the user's double-click speed for your timer (Control Panel: Mouse). You can access it with:
get_double_click_time():
""" Gets the Windows double click time in ms """
from ctypes import windll
return int(windll.user32.GetDoubleClickTime())
I haven't yet figured out how to grab the dclick time from Mac or Linux (but I also don't have a need to).
I am trying to implement a feature such that if the user havn't interact with the GUI for some time X, I will stop some functionality of the GUI.
Currently I have a time stamp set up so that if any of the button is not clicked in X seconds, the GUI will terminate some functionality
button1.triggered.connect(keep_alive)
button2.triggered.connect(keep_alive)
....
buttonN.triggered.connect(keep_alive)
As you can see, this is not really elegant, and doesn't scale as the button increases. Therefore I am currently investigating another method such that I monitor the mouse clicks
mouse = app.mouseButtons()
if mouse != Qtcore.Qt.NoButton:
#keep_alive
I think this is a little hacky, but it will work for the functionality I envisioned, however, I do not know how to insert this to the execution loop of the QT.
Any suggestions will be appreciated
You must intercept the mouse events by reimplementing the mousePressEvent.
http://qt-project.org/doc/qt-4.8/qwidget.html#mousePressEvent
To make sure that it won't affect your other functionalities you'll need to propagate it to the parent widget. Read more details: https://www.qt.io/blog/2006/05/27/mouse-event-propagation
I would proceed by implementing it in the main window and make sure all mouse events are propagated to it.
The following python line will bind the method "click" to the event when the user presses the mouse button while the pointer is on the widget; no matter where the pointer is when she releases the button.
self.bind('<Button-1>',self.click)
If I use "ButtonRelease" instead of "Button" in the code, it seems that the method "click" will be called for the widget on which the mouse was pressed after the button release; no matter where you release it.
1- Isn't there a neat way to make it call the bound method only if the mouse button was released on my widget; no matter where it was pressed?
2- Isn't there neat way to tell it to react only in case of a full click (press and release both on the same widget)?
1- Isn't there a neat way to make it
call the bound method only if the
mouse button was released on my
widget; no matter where it was
pressed?
2- Isn't there neat way to tell it to
react only in case of a full click
(press and release both on the same
widget)?
No "neat" way, because, as Tkinter's docs say:
When you press down a mouse button
over a widget, Tkinter will
automatically "grab" the mouse
pointer, and mouse events will then be
sent to the current widget as long as
the mouse button is held down.
and both of your desires are incompatible with this automatic grabbing of the mouse pointer on press-down (which I don't know how to disable -- I think it may be impossible to disable, but proving a negative is hard;-).
So, you need more work, and a non-"neat" solution: on the button-down event's callback, bind the enter and leave events (to bound methods of a class instance where you can track whether the mouse is currently inside or inside the widget of interest) of that window as well as the button-release; this way, when the release event comes, you know whether to perform the "actual application callback" (if inside) or do nothing (if outside) -- that gives you your desire number 2, but describing this as neat would be a stretch.
Desire number 1 is even harder, because you have to track enter and leave events on EVERY widget of interest -- it's not enough to know one bit, whether the mouse is inside or outside, but rather you must keep track of which widget (if any) it's currently in, to direct the "actual application callback" properly (if at all) at button release time.
While the internals aren't going to be neat, each functionality can be bound into one neat-to-call function... with slightly "indaginous" internals (a term that's used more often to refer to root canal work or the like, rather than programming, but may be appropriate when you're wanting to go against the grain of functionality hard-coded in a framework... that's the downside of frameworks -- you're in clover as long as you want to behave in ways they support, but when you want to defeat their usual behaviors to do something completely different, that can hardly ever be "neat"!-).
The tkinter documentation does provide you info on that:
http://www.pythonware.com/library/tkinter/introduction/events-and-bindings.htm
You can do a binding on
<ButtonRelease-1>
Binding on ButtonRelease-1 isn't enough. The callback won't fire until the button is released, but it doesn't matter where the mouse is when it's released. What governs is where the mouse was when it was clicked, as Alex Martelli's said. An easy way to get the desired behavior is to put everything on a canvas, and bind the callback to ButtonRelease-1. Now you have something like
def callback(event):
x1, y1, x2, y2 = canvas.bbox(widget)
if x1 <= event.x <= x2 and y1 <= event.y <= y2:
<whatever>
I've used this approach in my own code to get arbitrary widgets to behave like buttons in this respect.