There are recipes on how to change focus on mouse move or client change.
But what I want, is to prevent any window from stealing focus. E.g. I open a new terminal via the default meta-Enter shortcut, and when it opens it immediately steals focus. Is there any way to prevent it?
Yes, it's possible. Focus events can happen in many ways. In the case of the new clients, just comment the focus line in your rules.
For the focus follow mouse, remove the client.focus = c in the mouse::enter section of rc.lua
For specific clients, you can add focus filters:
https://awesomewm.org/apidoc/libraries/awful.ewmh.html#add_activate_filter
For the deepest and most advanced focus control, you can disconnect the default focus handler (awful.ewmh.activate) from the request::activate (Awesome 4.0+) signal and implement your own. In that case, you will have absolute control over every focus events.
Related
I find the graphical feedback when pressing buttons (WKInterfaceButton) in watchOS2 is very weak. It is hard to see and even Apple seems to thinks this is the case as they e.g. in the unlock screen change the background to white on active buttons. The default behaviour is to dim the whole button.
How can I make a button press cleared in watchOS 2? I can e.g. change the button text color on activity but how do I easily change it back when it is no longer active?
There is currently no way to detect touch-down, or other events, on WKInterfaceButtons like you can on UIButtons on iOS. The only touch event you can detect is touch-up-inside, which calls the IBAction method.
Therefore what you wish to accomplish cannot be accomplished. Something you might consider is animating the button appearance once the action has been triggered. For example in my app upon button tap I animate the button's background color, then animate it back to the original color. That provides more visual confirmation to the user so they are certain the button was tapped.
I'd encourage you to file an enhancement request at bugreport.apple.com if you'd like to have more control with touch events.
I am using an HTML5 video tag with videoJS (last stable release, 4.12). I have no trouble to get the loadedmetadata event but for some reason I probably missed, I can't hook using the "meteor way" on the video object play event.
My template events code:
Template.Player.events({
'loadedmetadata #video_player':function (e,t) {
console.log(e.target); //working fine
},
'play #video_player':function(e,t){
console.log("play!");//now it works
}
});
I am debugging on Chrome but i guess it is not browser related.
edit:
It appears that it works when I don't use id or class selectors. Since I have only one video tag on my template, I can catch the play event by doing this:
Template.Player.events({
'play video':function(e,t){
console.log("play!");//not working
}
});
I still don't buy the fact that meteor can't handle that. If so, why? What is the difference between loadedmetadata and play events that allows the first to use an id selector when the latter can't?
play triggers only when playback is resumed, playing triggers every
time playback starts.
#Oskar, you are right when I look at the documentation. However, in my case, play triggers both when starting a video and when resuming it after a pause.
First off, make sure you're using the correct event - play triggers only when playback is resumed, playing triggers every time playback starts.
Looking at the Meteor docs, these are the events that are "officially" supported:
Event types and their uses include:
click
Mouse click on any element, including a link, button, form control, or div. Use preventDefault() to prevent a clicked link from being followed. Some ways of activating an element from the keyboard also fire click.
dblclick
Double-click.
focus, blur
A text input field or other form control gains or loses focus. You can make any element focusable by giving it a tabindex property. Browsers differ on whether links, checkboxes, and radio buttons are natively focusable. These events do not bubble.
change
A checkbox or radio button changes state. For text fields, use blur or key events to respond to changes.
mouseenter, mouseleave
The pointer enters or leaves the bounds of an element. These events do not bubble.
mousedown, mouseup
The mouse button is newly down or up.
keydown, keypress, keyup
The user presses a keyboard key. keypress is most useful for catching typing in text fields, while keydown and keyup can be used for arrow keys or modifier keys.
Other DOM events are available as well, but for the events above, Meteor has taken some care to ensure that they work uniformly in all browsers.
In my Flex 4.9.1 application, at a particular point I put up a "sheet of glass" over the entire stage. It's purpose is to trap all mouse clicks until the user presses the escape key, which removes it. That part is easy and works well. It's just a FlexSprite, parented by the systemManager, which paints transparent pixels over the entire screen.
The problem is that, regardless of where the focus is before the glass is put up, or even if stage.focus is set to null, the user can press the tab key and focus text inputs beneath the glass, and enter text into them.
I tried listening for KEY_UP and KEY_DOWN events on the systemManager, with useCapture=true, and the highest possible priority (0x7FFFFF). When I get the events, I call stopPropagation(), stopImmediatePropagation(), and preventDefault() (even though the events are not cancelable) on them. Nothing works. No matter what, hitting the tab key several times will bring a textfield into focus, and typing letters will enter text into the fields.
So it appears that the text fields are not actually controlled by the key events they dispatch, as if the text is entered before the event is actually dispatched. Because presumably, if they were, they would listen at the target phase of the event flow. And as for the tab key, I have no idea why stopping its propagation doesn't prevent the focus switching.
Has anyone accomplished what I'm trying to accomplish before? If so, what worked?
You can use Application.application.enabled = false; to disable all the controls beneath the top-level Application while the "sheet of glass" is up.
See this answer for more details.
From what I see, QApplication::mouseButtons() may return no buttons even when a button is held down. This happens when you have clicked a side of a window for re-sizing. It's coherent with the docs because mouseButtons() reflects the state from the flow of QEvent::mouseButtonPress, etc. However, I need just to know if the button is held down. Does any one know if it's possible through the Qt API?
I think it's not possible. Mouse events outside an application's window are not passed to its event handlers. Dragging mouse borders is one of such events, it's processed by the window system. Another example is clicking on other windows. Usually an application doesn't know what the user does with other windows. You need to install system-wide event listener or use native API features(e.g. GetAsyncKeyState on Windows) to determine that. This behavior is unusual and possibly dangerous. In most cases it's not useful, and it seems that Qt doesn't have this ability.
I'd like to create a semi-transparent information window that doesn't get in the way of the user's other activities. Any clicks on the window should just pass through as if the window wasn't there.
How would you recommend implementing such behavior? Is there an easy way to do it or do I have to follow a clumsy workaround? I'm thinking of hiding the window, re-executing the click, then making the window visible again. But this would still screw up drag'n'drop gestures.
Take a look at an enum value of Qt::WidgetAttribute: Qt::WA_TransparentForMouseEvents:
When enabled, this attribute disables the delivery of mouse events to
the widget and its children. Mouse events are delivered to other
widgets as if the widget and its children were not present in the
widget hierarchy; mouse clicks and other events effectively "pass
through" them. This attribute is disabled by default.
I did a little more research into "mouse event transparency" (didn't know the exact terminology) and I found this.
I don't think there is a general and easy approach to your problem. You will probably have to dig into the native API. Once events reach an application they are not forwarded to other applications on their own.
What do you guys think? Am I doomed to work with the native APIs of each OS?