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.
Related
Program that I write often crashes leaving terminal in a S-Lang library state (similar to ncurses). I would want to add a check into development's branch Makefile main all target for such an improper state and and an automatic invocation of reset command. How to approach this task?
reset does two things; you can write a shell script which detects one of them:
it resets the terminal I/O modes (which a shell script can inspect using stty)
it sends escape sequences to the terminal (which more often than not will alter things in the terminal for which there is no suitable query/report escape sequence).
For the latter, you would find it challenging to determine the currently selected character set, e.g., line-drawing. If the terminal's set to show line-drawing characters, that's the usual reason for someone wanting to run reset (e.g., cat'ing a binary file to the screen).
There happens to be a VT320 feature (DECCIR) which can provide this information (which xterm implements):
but with regard to other terminals, you're unlikely to find it implemented:
(iTerm2 doesn't do it)
(nor does VTE). You can read an extract from the VT510 manual describing the feature on vt100.net
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.
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'm using KDE, and I'm toying with the idea of hacking the code for Dolphin File Manager (and potentially Konqueror if necessary) to get context-sensitive drag and drop behaviour (i.e. files are moved within the same partition, or copied if they're moved across partitions or the source is read only).
To do this, I think I'd need to find out the containing partition of the source and destination (easy enough on Windows using the drive letter, but on Linux, as mount points can be almost anywhere, it can't be reliably derived from the file path), and compare them.
Does anyone know how I can find out the partition that contains a given file?
It must be possible - I know Nautilus provides this sort of behaviour, but I'm not familiar enough with GTK to track down the appropriate section in the source code to see how its done...
Qt doesn't provide API for this. For POSIX, have a look at stat.
For KDE, you can use KIO::stat() to get mostly the same info as POSIX' stat function but asynchronously.
The device id should be in the field UDS_DEVICE_ID of the result.
My organization builds a C++ application that runs on multiple operating systems.
Should the build number, visible to customer, be the same for a given state of the source code tree on all the platforms?
Yes, I think so.
One practice you can use is to use the changelist number or however your source control system identifies the checkin that your build system pulled to build your product. That way you always know what source you should pull to rebuild it as well.
There aren't any downsides that I can see. You want to be able to reproduce the build, so each should say what the build is. If it's the same build, it should be the same build number.
If you choose to (or cannot - from a build process point of view) not use the exact same versionnumber for builds made for different platforms, you should document exactly what your versionnumbers actually imply.
If you don't, typically a user of the software will treat the whole thing (e.g. 3.1.0.333 - where 333 would be the build number) as identifying a certain version of the software (thuse the code tree). If they use your software on differnt platforms, they then might think that 3.1.0.333 and 3.1.0.334 are actually refering differnt versions (as in code changes) of the product, which they might not.
The same is true for outher "build number" styles, like using some sort of date/time derived build-id.
If you globally manage your build numbers, you might consider adding a platform ID. So that you can build 3.1.0.333-x86 and 3.1.0.333-amd64 one after the other, but still have them share the same "number". It will also be more obvious to the user what the indent/meaning is.