So, I've encountered a problem where Alacritty loses its focus upon being spawned. Say I have my browser open, I open Kate on top of that, it gains focus, but when I open Alacritty, it gains focus upon spawning, but then goes back to the last focused window (in this case Kate). This is really hard to notice, but if you use a brighter color of focused window or one that stands out, you can notice it. So far only noticed that with Alacritty, and with my limited knowledge about Awesome and Lua, I did something like this:
client.connect_signal("request::manage", function(c)
c:emit_signal("request::activate", {raise = false})
end)
but it also doesn't help it. I also have disabled "sloppy focus" (commented out), because I don't like it, but when I use it, it gives the focus to Alacritty normally, with no issues. Say my Alacritty spawns at x=500 y=250, and my cursor is at x=20 y=15 (out of focus even when it spawns), Alacritty does gain the focus, but again, when I remove sloppy focus, it no longer gets the focus.
Is there something I'm missing or is it just bugged? Sloppy focus literally fixes that issue, but I don't want to use sloppy focus because my mouse often flies on my desk for various reasons (typically because I'm stupid and hit it while grabbing something etc) and hence my focus swaps constantly.
Related
I am trying to implement keyboard accessibility in one of my website for blind people. I have a hamburger menu on my website. While navigating using the "Tab" key on the keyboard, the focus moves to this hamburger menu item. While clicking on "Enter", it will expand and while press the "Tab" key again, it is navigating through the open hamburger menu elements. Once the last item reached, it will focus on the content.
In that case, is it possible to close the hamburger menu once the user focus-out using the keyboard "Tab" keypress?
Example here https://www.impressivewebs.com/demo-files/hamburger-menu/. It is possible to close the side menu after focus out?
Short answer
It's possible, but it isn't a good idea.
You'd better use a classic toggle button.
Longer answer
For a blind person, doing something on focus out essentially means that it happens without notice. It may be hard to understand and is at best a source of confusion.
The elements that are successively reached in tab navigation and their order aren't supposed to change without explicit conscious user action.
It's even more confusing if the way in which the menu appears and disappears aren't symetric (in your case, explicit press enter vs. focus out).
Both should be symetric. This means that, whether:
The same button toggle the menu on and off
The menu appears on leaving the link just before the menu (focus in), and disappears when leaving the last item of the menu (focus out)
There are several important cons in implementing the second:
Tab isn't the only way to navigate on a page for screen reader users. This concretely means that the menu may not be reachable for no apparent reason, and there may not be any way to make it appear.
Keyboard-only users having vision will probably be surprised of unexpected appearance/disappearance of the menu
Technically it isn't as easy as it looks like: you must think about it in the two directions (tab and shift+tab)
The toggle button hasn't these problems. Correctly implemented, it's always reachable, explicitly triggered by the user and has predictable behavior.
Additionally, it's much simpler to implement.
To wrap it up, the classic toggle button is therefore by far the simplest and safest solution, both for you and for users of various kinds.
Where would the first focus be on when a modal window opens? Some say the focus order should be sequential, so the first tab stop should be on the close button and some say, it should be on the first logically actionable element.
According to me, it should be on the first actionable item. Let's say if a modal window is opened to Search something, then the focus should be on the search edit box.
What are your thoughts? Which is better and what are the reasons?
The answer is, it depends®.
In fact it's mostly a question of good sense. You should put the focus where the user is the most likely to do his first action in the modal. Therefore:
If you are prompting for input, the most logical is to put the focus on the first required field
If you are asking a yes-no or multiple choice question, the focus should go on the most probable or recommanded answer
Exception to the previous one: if you are asking a question about whether or not to proceed on a unrecoverable action such as "are you sure to delete ?", the focus should be set to the no button eventhough the most probable answer is yes, so that the user has a last chance to cancel something triggered by misstake
If the modal dialog is just showing a message, it's logical to put the focus on the OK or close button, since it's the only possible action
Putting the focus on the close button when something else is expected is kind of weird, especially for screen reader users, who don't necessarily know what the dialog is for immediately.
I always put it on the first heading or label, so blind users can confirm where they are after clicking the link or button which opened the modal. Then focus can move to the close button as the next item in sequence - if opening the modal was a mistake (happens often when you can't see the layout or with ambiguously labelled links) this makes it easy to correct.
Jumping to the first focusable item isn't technically wrong but gives poor usability for screenreader users while only saving one click for sighted keyboard users.
Background
I'm building an application which runs in the background, and where the mouse cursor is moved programmatically into a dialog when the dialog "pops up". I have done this using QCursor.setPos
Problem
The problem I'm having is that if the mouse button is pressed down when the user is interacting with something outside the application this might lead to unwanted things happening. For example if the user is changing the volume and the mouse is moved the volume might go to max or min
Question
Is there any way (in Qt) to do a mouseup programmatically?
If I do this before changing the position of the cursor it seems to me that there is less risk of problems (though there might be other problems resulting from this approach)
Lets say, you have an image button at the UI that represents a switchable feature (i.e. tooltips on/off). What should it show according to the status (on/off). I believe, the user is expecting to see a hint for what is going to happen, when he click the button. In this case, the button displays just the opposite of the current status. For example: the two images are lightbulbs, one grey for OFF, one yellow for ON. Now, if the feature status is OFF, the button shows the yellow one, signaling that, if you click on it, the feature will be switched to ON, and vice versa. A colleague said, that this is misleading. If the feature is OFF the button should reflect this, thus displaying a grey lightbulb. I couldn't find any best practice rules for that. Anybody knows some?
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...)