Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
Background: for the past five years or so, I have been using Mac hardware (high end MacBook Pro laptops for the most part) and software after many years of using Gnu/Linux on typical PC hardware with ergonomic keyboards. More importantly, as a heavy Emacs user, the switch to Mac was painful, with the Apple standard short keyboard both maddening and unavoidable. I prevented RSI onset by using the Karabiner tool to make two small but very important changes: 1) changing the capslock key to generate a menu (f13) key when pressed alone and a control key modified keycode when pressed with another key; 2) changing the return key in a similar fashion, get return when pressed alone and a control key modified keycode when pressed with another key. Disappointed with recent Apple decisions for both hardware and software, I am now moving back to Gnu/Linux (Ubuntu if it matters) but sticking with Mac laptops.
Question: since Karabiner is an OS X only tool with no readily available Gnu/Linux counterpart, it looks like I will have to write and/or modify some code to achieve the capslock and return key dual function behaviors Karabiner enables. The Karabiner author writes that xbindkeys and rbindkeys do key remapping but at first glance they do not seem to handle the dual function behaviors. Now I am wrestling with porting Karabiner or creating a new tool entirely. And no doubt there may be other approaches as well. So my question is: what programming advice would you suggest for solving this problem? Especially one that can be developed in hours, days or weeks rather than in months.
Notes:
1) There are different approaches involving changes of behavior such as swapping control and command keys. Many have been tried with varying degrees of satisfaction. Karabiner's dual function approach is, IMHO, far and away, the most effective in that it provides control key symmetry on the keyboard home row, and for all applications!
2) Different hardware is also likely to be suggested. I've tried Dell, HP, Lenovo, Acer systems and looked at a lot more. None are comparable to the combined power, size, feel, and style of the Apple top end products, albeit at a premium price. For example, the Dell Precision 7510 is bulky and has a trackpad that feels like sandpaper; the Lenovo X1 (a very nice system) lacks a Thunderbolt port; etc.
3) External keyboards are also a non-starter because of the laptop requirement; an external keyboard on the plane or train is not happening.
You can achieve this on Waylan, a TTY or X11 using Interception Tools, which talks directly with libevdev and libudev.
Wayland, TTY or X11
Install Interception Tools and a plugin such as caps2esc or interception-k2k. Then you need to configure Interception to use this plugin. For caps2esc, you can use the following /etc/udevmon.yaml file:
- JOB: "intercept -g $DEVNODE | caps2esc | uinput -d $DEVNODE"
DEVICE:
EVENTS:
EV_KEY: [KEY_CAPSLOCK, KEY_ESC]
Then run it as root:
nice -n -20 /usr/bin/udevmon -c /etc/udevmon.yaml
You should make sure it starts on login. For systemd, you can use the following service:
[Unit]
Description=udevmon
[Service]
ExecStart=/usr/bin/nice -n -20 /usr/bin/udevmon -c /etc/udevmon.yaml
[Install]
WantedBy=multi-user.target
X11-only
As an alternative or on older systems without udev, you can use setxkbmap and xcape.
First change Caps Lock to act as a Ctrl modifier:
setxkbmap -option caps:ctrl_modifier
Then set Caps Lock to act as Menu key when pressed for less than the timeout (the default is 500 ms):
xcape -e 'Caps_Lock=Menu'
xcape runs as a daemon, so you need to ensure it starts on login. setxkbmap sets the keyboard layout for the current X session only, you can set it permanently on xinitrc, xprofile or X configuration files.
P.S. For those that want to use an external keyboard, the open source (software and hardware) Ultimate Hacking Keyboard (UHK) allows this functionality.
Related
I have recently moved to Linux full time, and am enjoying the learning curve. However, one particular thing has me stumped big time: Some of the Fn key combinations on my laptop are not working, spec. Volume up/down, Mute, etc. Combinations that are working include WLAN, Sleep, Video cycle, numeric pad, etc. I can rule out a H/W fault, since the keys worked perfectly fine on Windows 7 (although only when the hotkeys software by the laptop maker was installed).
I have scoured the net for possible explanations, and have come across the concepts of scancode (HW dependent), keycode and keysym. I think I understand the basics, and have found that console and X have their own mappings, and need to be remapped separately. The console uses the kernel mapping of scancodes to keycodes, but X for some reason has its own mapping. For my part, I have tried:
Set the boot parameter atkbd.softraw=0
Switched to console mode by Ctrl + Alt + F1
Used showkey --scancodes. Unfortunately, the keys that I am trying to get working do not show any scancode output
Used dmesg to see if any Unknown key pressed events have occured, but none found.
In my desperation, tried acpi_listen to see if the keys were actually firing any acpi events instead, only sleep and video cycle keys do, others do not output anything
At this point, I thought maybe I should try getting scancodes from the X environment itself, using xev, but no luck.
I have come here as a last resort only. I hope somebody has a good explanation as to why some of the function key combinations are not generating any output in the tools I have tried above. If it helps, I am using Linux Mint 17.3 Cinnamon, and the laptop is made by HCL. evtest shows the keyboard device to be AT Translated Set 2 keyboard. If more info is needed, I would be happy to oblige. Thanks.
EDIT: No relevant BIOS setting is available.
Confession: All my knowledge on this is based on what I have been reading up on Arch wiki, Ubuntu wiki, a whole lot of forum posts and other websites. So, if I am technically wrong about something, please bear with me, and correct me. I love learning this stuff :)
Yes, some keys on USB keyboards might not generate a scan code sent via the USB HID keyboard protocol but instead use a different USB protocol to communicate some user input. From what you've described, that's most likely what's happening here. You may be able to use programs from the evmu-tools package (that's the Debian name) or the older evtest program to find out more about what your particular device is doing for things that appear not to be sending keyboard scan codes.
(It also seems, from reading The Unix & Linux SE question "How to get all my keys to send keycodes" that there's something going on with keycodes above 255, but I'm not clear on what's going on there.)
There's also an error in your understanding of the layering:
The console uses the kernel mapping of scancodes to keycodes, but X for some reason has its own mapping.
This is not quite correct. The kernel maps scan codes to keycodes between 1 and 255; you can see this mapping with getkeycodes(8) and change it with setkeycodes(8) or udev. (The Arch Wiki page Map scancodes to keycodes has many details on this.) Not all scan codes have a mapping to a keycode; receipt of a scan code with no translation entry are what you would have seen in dmesg, had there been any.
Only after the scan code is converted to a kernel keycode do the console and X11 have access to these; each has its own mechanism to translate keycodes to actions.
Note that the console program showkey -s does not show actual scan codes that have been received; it reads keycodes (as shown by showkey -k) and translates those back into scan codes using the kernel table shown by getkeycodes(8).
It might depend upon the X11 window manager. You should try using xev(1) to understand what is going on.
Maybe using some other desktop suite like xfce or lxde or gnome, kde, icewm might help
Maybe configuring explicitly your keyboard (e.g. in /etc/Xorg.conf...) might help.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I'm looking for recommendations for an easy-to-use GUI automation/macro platform for Linux.
If you're familiar with AutoHotkey or AutoIt on Windows, then you know exactly the kind of features I need, with the level of complexity. If you aren't familiar, then here's a small code snippet of how easy it is to use AutoHotkey:
InputBox, varInput, Please enter some random text...
Run, notepad.exe
WinWaitActive, Untitled - Notepad
SendInput, %varInput%
SendInput, !f{Up}{Enter}{Enter}
WinWaitActive, Save
SendInput, SomeRandomFile{Enter}
MsgBox, Your text`, %varInput% has been saved using notepad!
#n::Run, notepad.exe
Now the above example, although a bit pointless, is a demo of the sort of functionality and simplicity I'm looking for. Here's an explanation for those who don't speak AutoHotkey:
----Start of Explanation of Code ----
Asks user to input some text and stores it in varInput
Runs notepad.exe
Waits till window exists and is active
Sends the contents of varInput as a series of keystrokes
Sends keystrokes to go to File -> Exit
Waits till the "Save" window is active
Sends some more keystrokes
Shows a Message Box with some text and the contents of a variable
Registers a hotkey, Win+N, which when pressed executes notepad.exe
----End of Explanation----
So as you can understand, the features are quite obvious: Ability to easily simulate keyboard and mouse functions, read input, process and display output, execute programs, manipulate windows, register hotkeys, etc. - all being done without requiring any #includes, unnecessary brackets, class declarations, etc. In short: Simple.
Now I've played around a bit with Perl and Python, but it's definitely not AutoHotkey. They're great for more advanced stuff, but surely, there has to be some tool out there for easy GUI automation, right?
PS: I've already tried running AutoHotkey with Wine, but sending keystrokes and hotkeys don't work.
I'd recommend the site alternativeto.net to find alternative programs.
It shows three alternatives for AutoIt: AutoKey, Sikuli, and Silktest. AutoKey seems up to the job.
IronAHK is being developed as a cross-platform flavor of AutoHotkey which can be used on Linux, but it's not a fleshed out product yet.
Sikuli lets you automate your interface using screenshots. It runs on any Java platform, so it is cross-platform.
You should look at Experitest. I'm using the Windows version, but it's Java-based and I think it supports Linux as well.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
OK, so back before ice age, I recall having a Sinclair ZX80 PC (with TV as a display, and a cassette tape player as storage device).
Obviously, the programs on cassette tapes made a very distinct sound (er... noise) when playing the tape... I was wondering if someone still had those tapes?
The reason (and the reason this Q is programming related) is that IIRC different languages made somewhat different pitched noises, but I would like to run the tape and listen myself to confirm if that was really the case...
I have the tapes but they've been stored in the garage at my parents' house and the last thirty years hasn't been kind to them.
You can get images here though: http://www.zx81.nl/dload if that's any use. Perhaps there is a tool out there for converting from the bytes back to the audio ;)
Edit: Perhaps here: http://ldesoras.free.fr/prod.html#src_ay3hacking
On the ZX80, ZX81 and ZX Spectrum, tape output is achieved by the CPU toggling the output line level between a high state and a low state. Input is achieved by having the CPU watch an input line level. The very low level of operation was one of Sir Clive's cost-saving measures; rival machines like the BBC Micro had dedicated hardware for serialisation and deserialisation of data, so the CPU would just say "output 0xfe" and then the hardware would make the relevant noises and raise an interrupt when it was ready for the next byte. The BBC Micro specifically implements the Kansas City Standard, whereas the Sinclair machines in every instance use whatever adhoc format best fitted the constraints of the machine.
The effect of that is that while almost every other machine that uses tape has tape output that sounds much the same from one program to the next by necessity, programs on a Sinclair machine could choose to use whatever encoding they wanted, which is the principle around which a thousand speed loaders were written. It's therefore not impossible that different programs would output distinctively different sounds. Some even used the symmetry between the tape input and output to do crude digital sampling, editing and playback, though they were never more than novelties for obvious reasons.
That being said, the base units of the ZX80 and ZX81 contained just 1kb RAM so it's quite likely that programmers would just use the ROM routines for reading and writing data, due to space constraints if nothing else. Then the sound differences would just be on account of characteristic data, as suggested by slugster.
I know these come up on auction sites like Ebay quite frequently - if you want to buy them yourself. If you get someone else who owns one to listen then you are going to get their subjective opinion :)
In any case, the language used to save it would be the secondary cause of the pitch changes - it will be related to the data. IOW you could probably create a straight binary data file that sounded very similar to a BASIC program (the BASIC would have been saved as text, as it is interpreted).
I know the threads old but... I was playing about with something similar last night and I've got a wav of an old zx81 game if you're still interested? pm me and I'll post it somewhere.
You can use something like http://www.wintzx.fr/ or pick something from http://www.worldofspectrum.org/utilities.html#tzxtools to convert an emulator file to an audio file and then you can just play it on your PC. Some tools also allow you to play the file directly. Emulator files can be found at http://www.zx81.nl/files.html and many other places.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I've considered the following:
Logitech Desktop MX 5500
Microsoft Wireless Entertainment Desktop 8000
But I'd like see what other programmers would recommend.
I know you're looking for a set, but these two topics might be of interest:
https://stackoverflow.com/questions/687/keyboard-for-programmers
https://stackoverflow.com/questions/53132/mouse-for-programmer
Personally, I prefer to buy my stuff separately so I can find the best of both. For example, I'm currently using an Apple Keyboard and a Logitech MX Revolution mouse and I've been very impressed with both.
Being a 60 wpm typist on average, I can assure you that a wireless keyboard will only cause you frustration in the long run. It's gotten to the point where I actually swapped back in a wired keyboard because I have yet to find a wireless keyboard that can keep up with me.
Maybe it is because I have always loved the happy hacker keyboard, but I really like the very compact Apple's Bluetooth Keyboard (which does work with windows). But I really dig it's sleak design, and standard(ish) layout. The layout which matches my laptop, so that I can continue to touch type backslashes. for a mouse I am admitaditly less picky, and use either a mighty mouse or a Logitech V270 Bluetooth Travel Mouse.
I've used several, and the most durable bulletproof so far has been my Dell bluetooth pair. It's the same physical setup as the industrial-grade connected units. The bluetooth transmitter has been compatible for other devices as well. Good battery life, two AA's for the mouse and 3 AAA's for the keyboard - at least 6 weeks for a set of NiMH's.
I throw them in my backpack and take an extra bluetooth transmitter and they invariably work on clients' computers.
(source: dell.com)
All the logitechs, microsofts, and probably a half-dozen other off-brands haven't compared.
I use KeyTweak for the Ctl/CapsLock swap - actually I don't swap them - I have no use for a Caps Lock key.
I would avoid the Logitech MX5000/MX5500. If you can get something that is not Bluetooth, that would be best. The Bluetooth stack that Logitech uses is buggy. The keys like to get "stuck" which means they will act like they are pressed even when you release. That is especially bad if the key that gets stuck is backspace or delete. I've never had problems with their non-Bluetooth stuff.
Not a recommendation, as such, but a bit of guidance: many (but not all) wireless keyboards and mice "swallow" the first keystroke or split second of movement when you activate them after being idle. It's almost as though they go to sleep or something.
I've seen this with both Logitech and Microsoft wireless kit, as well as a third (relatively unknown) brand.
Your usage style might not be affected - but the missed mouse clicks and keystrokes drive me bonkers whenever I'm using a colleagues PC. Pause for thought, deside what to do next and then lose my train of thought when the machine doesn't respond. Arrrggh!
My advice: Whatever kit you settle upon, make sure you have the chance to try it out properly - in person - before committing your hard earned cash
I don't think there is a "best" here. I think you have to scope out components that feel right to you, perform well, and are in your price range.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Pretty much every other editor that isn't a vi descendant (vim, cream, vi-emu) seems to use the emacs shortcuts (ctrl+w to delete back a word and so on)
Early software was often modal, but usability took a turn at some point, away from this style.
VI-based editors are total enigmas -- they're the only real surviving members of that order of software.
Modes are a no-no in usability and interaction design because we humans are fickle mammals who cannot be trusted to remember what mode the application is in.
If you think you are in one "mode" when you are actually in another, then all sorts of badness can ensue. What you believe to be a series of harmless keystrokes can (in the wrong mode) cause unlimited catastrophe. This is known as a "mode error".
To learn more, search for the term "modeless" (and "usability")
As mentioned in the comments below, a Modal interface in the hands of an experienced and non-fickle person can be extremely efficient.
Um... maybe there isn't much of a need for one, given that Vi/Vim is pretty much available everywhere and got the whole modal thing right? :)
I think that it's because vi (and its ilk) already occupies the ecological niche of modal editors.
The number of people who prefer modal and haven't yet been attracted to vi is probably 0, so the hypothetical vi competitor would have to be so great as to make a significant number of vi users switch. This isn't likely. The cost of switching editors is huge and the vi-s are probably already as good as modal editors go. Well, maybe a significant breakthrough could improve upon them, but I find this unlikely.
#Leon: Great answer.
#dbr: Modal editing is something that takes a while to get used to. If you were to build a new editor that fits this paradigm, how would you improve on VI/VIM/Emacs? I think that is, in part, an answer to the question. Getting it "right" is hard enough, competing agains the likes of VI/VIM/Emacs would be extremely tough -- most people who use these editors are "die hard" fans, and you'd have to give them a compelling reason to move to another editor. Those people who don't use them already are most likely going to stay in a non-modal editor. IMHO of course ;)
Modal editors have the huge advantage to touch typists that you can navigate around the screen without taking your hands off the home row. My wrists only hurt when I'm doing stuff that requires me to move my hand off the keyboard and onto the mouse or arrow keys and back constantly.
Remember that Notepad is a modal editor!
To see this, try typing E, D, I, T; now try typing Alt, E, D, I, T. In the second case the Alt key activates the "menu mode" so the results are different. :oP People seem to cope with that.
(Yes, this is a feature of Windows rather than specifically of Notepad. I think it's a bad feature because it is easy to hit Alt by mistake and I don't think you can turn it off.)
VIM and emacs make about as much user interface design sense as qwerty. We now have available modern computer optimized key layouts (see the colemak layout and the carpalx project); it's only a matter of time before someone does the same for text editors.
I believe Eclipse has Vi bindings and there is a Visual Studio plugin/extension, too (which is called Vi-Emu, or something).
It's worth noting that the vi input models survival is in part due it's adoption in the POSIX standard, so investing time in learning would mean your guarenteed to be able to work on any system complying to these standards. So, like English, theres power in ubiquity.
As far as alternatives go, I doubt an alternate model editor would survive a 30 day free trial period, so its the same reason more people drive automatics than fly jets.
Since this is a question already at odds with the "no subjective issues" mantra, allow me to face that head on in kind.
Non-Modal editing seeks to solve the problem caused by non-modal editing in the first place.
Simply put, with Modal editing I can do nearly everything without my hands leaving the keyboard, and without even tormenting my pinky with reaching for the control, or interrupting my finger placement by hunting for the arrow keys.
Reaching for mouse completely interrupts the train of thought. I have hated the intense reliance upon this with Intellij IDEA and Netbeans for many years. Even with vim-style addons.
Most of what you do has to do with fine-tuning with very small increments and changes within the same paragraph of code. Move up, move over, change character, etc., etc. These things are interrupted with control keys and arrows and mouse.
Though not really answering your question, there used to be a "modal like" way to write Japanese on cell phones before :
The first letter you hit was a conson let's say K, and then, and then the next key you would hit would have the role of a conson. (Having two conson in a row is impossible in Japanese)
Though it was main a few years ago, today it's only used by people who really want to hit fast.
I think the answer to the question is actually there are quite a few modal text editors that aren't forks of vi/vim. However they all use the vi key bindings. Vi users get the key bindings into their muscle memory so relearning a different set of key bindings would be really hard, so no-one would create a different set of key bindings.
But lots of different editors have re-implemented the vi key bindings from scratch. Just look at this question about IDEs with vi key bindings. At least half of the answers are editors built from scratch that implement vi key bindings, not versions of vi embedded.
I recently came across divascheme - an alternative set of key bindings for DrScheme. This is modal, and part of the justification is to do with RSI - specifically avoiding lots of wrist twisting to hit Ctrl-Alt-Shift-something. The coder has done an informal survey of fellow coders and found that emacs users suffered from more wrist pain than vi coders.
You can see him doing a short talk at LugRadio Live USA. (The video is a series of 5 minute talks and I can't remember how far through it is, sorry - if someone watches it and posts that here I'll edit this post to say when in the video it is).
Note I have not used divascheme.
The invention of the mouse took one mode and moved it to an input device, and context menus took another mode and moved it to a button. Ironically, the advent of touch devices has had the reverse effect, producing multi-modal interfaces:
aware multi-modal - touch and speech are aware of each other and intersect
unaware multi-modal - touch and speech are unaware of each other and conflict
The traditional WIMP interfaces have the basic premise that the information can flow in and out of the system through a single channel or an event stream. This event stream can be in the form of input (mouse, keyboard etc) where the user enters data to the system and expects feedback in the form of output (voice, vibration, visual, etc) when the system responds. But the channel maintains its singularity and can process information one source at a time. For example, in today’s interaction, the computer ignores typed information (through a keyboard) when a mouse button is depressed.
This is very much different from a multimodal interaction where the system has multiple event streams and channels and can process information coming through various input modes acting in parallel, such as those described above. For example, in an IVR system a user can either type or speak to navigate through the menu.
References
User Agent Accessibility Guidelines working group (UAWG): Keyboard Interface use cases
W3C Multimodal Standard Brings Web to More People, More Ways
Next steps for W3C work on Multimodal Standards
The Future of Interaction is Multimodal
Beyond Mouse and Keyboard: Expanding Design Considerations for Information Visualization Interactions - naturalinfovis_infovis2012.pdf
Setting the scope for light-weight Web-based applications
Jan. 26, 1983: Spreadsheet as Easy as 1-2-3
Multi-modal design: Gesture, Touch and Mobile devices...next big thing? | Experience Dynamics