I'm testing WKPanGestureRecognizer on my Apple Watch Series 7. It seems the pan gestures are always ended after about 6-7 seconds.
When I lift my finger before that timespan ends, everything behaves as I would expect it: the gesture event fires once with a state of ended, and the gesture is finished.
But when I let my finger on the screen, it receives the ended state too, always 6 or 7 seconds after the gesture had started. It does not depend on how much I move the finger around.
Is that a bug, or is that configurable or documented somewhere?
Related
I have a button which when clicked will run back-end process for, say, 10 sec.
I would like to make the button in pressed state till the process completes and then the button be released. This is, so that the user knows when the process is complete. As an example:
QString ExButtonStyleSheet = "QPushButton{background-color:lightgreen;}\
QPushButton:hover{background-color:yellow;}\
QPushButton:pressed{background-color:green;}\
QPushButton:disabled{background-color:grey;}";
In the above case, once clicked the button goes to hover state (yellow) even when the process is running (GUI is also busy) and turns lightgreen once free.
But this is not very explicit to the user, unlike the pressed state.(Note the above stylesheet is just an example and in my actual styesheet the hover state color is only slightly different from the normal.)
I am looking for a solution where the button remains to look pressed and only to be released when the process is complete.
You can theoretically use
QPushButton::setCheckable(true)
QPushButton::setDown(true) // Button is down
// Expensive task
QPushButton::setDown(false) // Button is released
Freezing the GUI for 10 seconds is a very bad idea.
You should use threads for your expensive tasks instead of blocking the GUI. Call QPushButton::setDown(true) and emit a signal to the thread which contains the code of the expensive task.
When the thread finishes the thread should call a slot in your MainWindow that contains QPushButton::setDown(false). This way your GUI will be fully responsive during the time and you follow the good coding behaviours.
I have written an Apple Watch app with a complication that works well. But I often accidentally click on that complication, and it opens my watch app.
Is there some attribute to tell the complication that there is no action when I click on it?
As an example, the sunrise/sunset complication has no click action.
No. There is no ClockKit feature which would stop it from launching your app when you (inadvertently) tap your complication.
You can, however, slide your finger away from your complication, which will deselect it, and avoid opening your app.
You can get a feel for this by long pressing your complication, which will indicate that it's selected. If you slightly swipe away from it, it will deselect itself. If you swipe too far, you may bring up a glance or notification.
Apart from deselecting the complication, I'm not sure that there would be a way to handle any inadvertent-versus-intentional interaction, where you might not want the app to be launched. If you can come up with a case, you should submit a feature request to Apple.
I have a certain screen in an apple watch application that I would like to lock or freeze, so that it displays when I rotate my wrist
Right now when I go to this screen and turn or move my wrist, the watch shuts off. Is there a way to prevent this from happening for a particular screen?
Unfortunately, there is no WatchKit method that allows you to control the app suspension behavior.
I have a callback that does some work when the mouse is moved. It feels weird not to govern it to a maximum rate. What governs how often mouse callbacks occur when the user moves the mouse?
The mouse device driver. If you change mouse settings on the configuration panel of your system you will see a behavior difference. The window system send those events to the main process, which are handled by the QApplication and then propagated to the right widget.
Unless no event filter has been set, the events delivery at a widget is as seamless as in a native app. After all the Qt event system match what different OS use for their window event system.
If something feels weird double check your callback implementation. It is very unlikely that the issue is somewhere else.
I think it depends on the mouse’s polling rate. Mouse polling rate is how often it reports its position (measured in Hz). For example a mouse with 125 Hz polling reports its position 125 times in a second (Every 8 milliseconds).
A higher polling rate can lead to a more callback in your case when you move the mouse. But it will also use more CPU resources.
Something seems to have changed in Qt 5: you can't get a drop or move event if you don't move at least one pixel from the start point where you were when QDrag::exec() was called. Try putting a breakpoint in the dropEvent of the Draggable Icons Sample, then click a boat and release it without moving the mouse. That generates an "ignore" without any drop signal.
(This is on Kubuntu 13.10 with Qt 5.1.)
When teaching how to start a drag operation, the documentation suggests you might use manhattanDistance() to determine if the mouse has moved enough to really qualify as "the user intending to start a drag". But you don't have to use that; you can start up a QDrag on the click itself.
Anyone know of a workaround to have that same kind of choice on the drop side, or is that choice gone completely? :-/
Why I care: I've long had frustrations trying to get a tight control on mouse behavior in GUI apps—Qt included. There seems to be no trustworthy state transition diagram you can draw of the invariants. It's a house of cards you can disprove very easily with simple tests like:
virtual void enterEvent(QEvent * event) {
Q_ASSERT(!_entered);
_entered = true;
}
virtual void leaveEvent(QEvent * event) {
Q_ASSERT(_entered);
_entered = false;
}
This breaks all kinds of ways, and how it breaks depends on the platform. (For the moment I'll talk about Kubuntu 13.10 with Qt 5.1.) If you press the mouse button and drag out of the widget, you'll receive a leaveEvent when you cross the boundary...and then another leaveEvent when the button is released. If you leave the window and activate another app in a window on screen and then click inside the widget to reactivate the Qt app, you'll get two consecutive enterEvents.
Repeat this pattern for every mouse event, and try and get a solid hold on the invariants...good luck! Nailing these down into a bulletproof app that "knows" it's state and doesn't fall apart (especially in the face of wild clicking and alt-Tabbing) is a bit of a lost cause.
This isn't good if your program does allocations and has heavy processing, and doesn't want to do a lot of sweeping under the rug (e.g. "Oh, I was doing some processing in response to being entered... but I just got entered again without a leave. Hm, I guess that happens! Throw the current calculations away and start again...")
In the past what I've done is to handle all my mouse operations (even simple clicking) with drag & drop. Getting the OS drag & drop facility involved in the operation tended to produce a more robust experience. I can only presume this is because the testers actually had to consider things like task switching with alt-Tab, etc. and not cause multiple drop operations or just forget that an operation had been started.
But the "baked in at a level deeper than the framework" aspect actually makes this one-pixel-move requirement impossible to change. I tried to hack around it by setting a timer event, then faking a QMouseEvent to bump the cursor to a new position once the drag was in effect. However, I surmise that the drag and drop is hooked in at the platform level, and doesn't consult the ordinary Qt event queue: src/plugins/platforms/xcb/qxcbdrag.cpp
The issue has--as of 1-May-2014--been acknowledged as a bug by the Qt team:
https://bugreports.qt-project.org/browse/QTBUG-34331
It seems that me bountying it here finally brought it to their attention, though it did not generate any SO answers I could accept to finalize the issue. So I'm writing and accepting my own. Good work, me. (?) Sorry for not having a better answer. :-/
There is another unfortunate side effect of the Qt5 change, pointed out by a "Dmitry Mordvinov":
Same problem here. Additionally app events are not handled till the first mouse event after drag started and this is really nasty bug. For example all app animations are suspended during that moment or application hangs up when you try to drag with touch monitor.
#dvvrd had to work around it, but felt the workaround was too ugly to share. So it seems that if you're affected by the problem, the right thing to do is go weigh in...and add your voice to the issue tracker to perhaps raise the priority of a solution.
(Or even better: patch it and submit the patch. 'tis open source, after all...)