For some reason, my mod key no longer activates any of the key bindings and I can't use the shortcuts.
I use gentoo, use vi + tmux + urxvt. I have tmux mapped to Ctrl + a. I'd been using the default mod key (windows logo) to activate awesome. I have an rc.lua file that I configure under .config/awesome, and it hasn't changed during updates. This has been running fine.
When running xev, and pressing the mod key, no events appear at all. Yet the keyboard and all keys work fine on another machine.
Anyone have thoughts why the mod key isn't triggering anything?
(note: this answer belongs more to superuser.com rather than stackoverflow.com)
There is multiple ways this can happen. One of them is changing the keyboard layout "the wrong way". However, the most likely (and facepalm) way it happens is that some keyboards manufacturer consider this a feature.
If you have a Logitech or other brands of gaming keyboards, they usually have a little switch to disable the windows key to prevent accidental hits from the palm of your hand when pressing w/a/s/d. Maybe you hit that switch by mistake?
Another way is that you mapped Super_L to a keybinding, but I guess you would have noticed this.
Related
I have this in my keymap.cson file:
'body':
'ctrl-alt-left': 'editor:select-to-first-character-of-line'
But it doesn't work (there is no effect).
The following keymaps do work:
'body':
'ctrl-alt-a': 'editor:move-to-beginning-of-line'
'ctrl-alt-e': 'editor:move-to-end-of-line'
'ctrl-alt-shift-s': 'editor:select-to-first-character-of-line'
'ctrl-alt-shift-w': 'editor:select-to-end-of-line'
But I would like to be able to use the arrow keys.
I'm not sure where you got the body selector from. You should use atom-text-editor for maps like this, as in the examples in the default keymap.cson in your .atom folder. This should do what you want:
'atom-text-editor':
'ctrl-alt-left': 'editor:move-to-beginning-of-line'
'ctrl-alt-right': 'editor:move-to-end-of-line'
'ctrl-alt-shift-left': 'editor:select-to-first-character-of-line'
'ctrl-alt-shift-right': 'editor:select-to-end-of-line'
When debugging issues like this, you must also keep a couple of other things in mind.
First, the meaning of alt varies by platform. On macOS, it means the Option key. On Windows or Linux, I believe it means the key labeled Alt, but your keyboard may be a bit different (especially non-US layouts).
Second, if a higher layer of the system (the OS itself, i.e. the window manager) is capturing a key combination, then it will never reach Atom at all. You can detect this situation using the Key Binding Resolver. You can activate it using Cmd. on macOS. I am not sure about other platforms, but usually Cmd on macOS maps to Ctrl on Windows and Linux, so I would suggest Ctrl..
While the Key Binding resolver is active, any keys or key combinations you press are listed in the resolver, along with the action (if any) within Atom that is taken. You can use this to determine what Atom thinks a given key is, and you can also use it to detect whether a given key combination is not reaching Atom in the first place.
So I need to now how safe the QLineedit is for inputting passwords. I made a simple window with a single lineedit set into password echo mode. Let's say I types some word there. Now I need to somehow grab this word from the program's memory and monitor it (for wxample to see if it's still there after I cleared the edit or typed another word). However when I used the mmory inspectors like CheatEngine or GameConqueror their outputs didn't have this word. (And when I set the some internal variable in the program it was in both outputs allright)
Am I doing something wrong or does it mean that QLineEdit is secure?
It is not secure, and it's not meant to be.
The data is there and also extremely easy to reach (you're probably not seeing it because of the UTF-16 encoding, but just try GammaRay against any Qt application and you'll see marvels).
I'm also wondering about your definition of "secure". Like anything else in computing: if you let an attacker get too close, you'll lose. End of the story.
If you're fighting against an attacker with capabilities of inspect your application's memory, there's almost nothing you can do to prevent them to eavesdrop to anything that goes on in your application, including processing the individual keypresses when you type the password.
This seems a rather silly question: but I can't find (for more than an hour) now a button to "reset" all standard windows.. I accidentally closed quite a lot of them during a crash. (Especially the "command window" and the signals-in-region during simulation seem to be gone permanently).
From "ModelSim User’s Manual, v10.1d", appendix F:
Most user GUI preferences are stored as Tcl variables in the .modelsim file on Unix/Linux
platforms or the Registry on Windows platforms.
You may consider to look into .modelsim, and possibly delete it, together with .modelsim.bak. The motivation for this suggestion is that .modelsim contains setup details for the layout of panes. .modelsim will (should!) be regenerated next time you open modelsim.
At the menu bar (main window), click on layout and then choose reset. Most of the windows will be reset.
I'm a newcomer to Qt, but I'm trying to implement what basically amounts to a video-game-esque input loop in a Qt application (crazy, I know, but see if you can help). I need accurate, one-to-one event handling for key presses and key releases, for all keys, including modifiers, no matter how weirdly you chord-up the keyboard.
Of course, your main access to key events is through QKeyEvent. But let's say the following happens:
user presses and holds Ctrl
user presses and holds Up
user releases Ctrl and Up simultaneously
As far as I can tell, what I get from Qt is:
QKeyEvent for the pressing of Ctrl, by itself (Qt::Key_Ctrl)
QKeyEvent for the pressing of Up, by itself (Qt::Key_Up)
QKeyEvent for the releasing of Ctrl+Up, with key() == Qt::Key_Up and the Ctrl bit reflected in a modifier change.
This may be not exactly accurate, but it's my best guess as to what's going on from way too much debugging of the issue. In any event, the key release events when modifiers are involved are incredibly unreliable.
The Ctrl+Up sequence there at the end is the problem. Now, I know I'm getting modifier state in e->modifiers(), and I'm getting the key press in e->key(). I could do some complicated hacks, trying to remember the modifier state internally, to detect when the user's released the modifier. But then, the Qt docs inform me, speaking of e->modifiers(), that:
This function cannot always be trusted. The user can confuse it by pressing both Shift keys simultaneously and releasing one of them, for example.
This is exactly the case I'm trying to avoid.
Is there any reliable way to keep track of one-to-one key presses and releases, for both normal and modifier keys, in Qt? If not, what's the closest you can get?
EDIT: I can refine this a little bit. It seems that if you hold down Cmd on a Mac, press a few keys (letter keys, say), release them, then release Cmd, you don't get release events for the letter key releases. I'm going to try to isolate a small example and see if this is actually a Qt bug.
I think if you are getting very specific with the keyboard, you are going to have leave Qt and get something that is OS specific, or you need to handle the Qt events before any filtering happens.
Handle Qt Events Before Filtering
Accelerators in Qt look for and wait on Alt+__ combos and you can set up Ctrl+__ combos to be listened to by QAction.
Both of these types of Objects built into QApplication and the general GUI environment, might be interrupting the messages you are getting, and giving you less than what you are expecting.
Qt Documentation: The Event System ... this part has a link to this...
QCoreApplication::notify() ... which tells the highest level that a Qt Application can be written to handle input using the Qt API:
Installing an event filter on QCoreApplication::instance(). Such an event filter is able to process all events for all widgets, so it's just as powerful as reimplementing notify(); furthermore, it's possible to have more than one application-global event filter. Global event filters even see mouse events for disabled widgets. Note that application event filters are only called for objects that live in the main thread.
OS Specific Keyboard Handling Alternative
If looking at debug statements from a Qt event filter installed at the level mentioned above yields the same results as what you mentioned in your question, then you will need to go to the OS specific keyboard input stuff. For example in Windows you would need to scan the keyboard and or look at the VK state of the whole keyboard and do something with it (with something like GetKeyboardState() ).
I know it's a bit late to answer this question. Still... I have the same problem with Mac key release events and there is an open bug QTBUG-36839.
On Windows you may implement keyboard hook to catch every key presses/releases. But even that is not reliable in some cases. E.g. if you will type lock screen shortcut after unlocking you will NOT see any key release. I guess there must be something similar to hook on Mac. If it is important to you to remember what exactly physical key user pressed - I think this is one of the best ways. At the same time, from my experience, doing something low-level takes a lot of time and may bring a weird bugs in cases you never could imagine. So the question is: are you sure you cannot make what you need with something like QAction?
Or maybe you could just use Control instead of Command in your shortcuts :)
I've been testing typing inside textInput components with the Windows Japanese IME turned on. All works well out of the box, which is awesome. One (fairly specific) question I have, though, is about typing numbers. It seems from my limited experience that numbers typed in default to Zenkaku (2 bytes) which don't seem to be accepted by the textinput as committed values. One can switch to Hankaku (1 Byte) notation by pressing F10 and the commit works. My question is about what's acceptable to a user. From my uninformed standpoint it seems like having to press F10 would be super annoying for a user and thus either the textInput should accept Zenkaku values or it should default to typing Hankaku (both of which I assume may be possible with a little bit of code on focusIn or ValueCommitted). But then again, it could very well be that this is in fact the standard behavior for most web apps in Japanese and thus not annoying at all. In fact, there may be a great reason for why Zenkaku happens by default.
Would love to hear any thoughts from anyone who has dealt with localizing to Japanese, or any advice on web resources where an answer to such a question could be found.
thank you
f
I'm a Japanese web-app developer, without no skills about adobe flex. Sorry for non-flex-specific answer.
Most Japanese Windows users can switch IME on/off with "半角/全角" key. (Macintosh : "かな" key & "英数" key) It's easier than pressing F10 after typing numbers. With announcement to type numbers in Hankaku, such as "半角で入力して下さい", most Japanese users will type in Hankaku.
Other methods
Switch off IME with CSS (works only in MS-InternetExplorer.)
// IE6
ime-mode: disabled;
// IE8
-ms-ime-mode: disabled;
Convert Zenkaku numbers to Hankaku automatically.