Is there any way to tap on keypad button in calabash -android (like :1,2,3,4)
Note : Tap should be physical tap , as we got with "keyboard_enter_text" command in iOS
For Android you can use keyboard_enter_text"1,2,3,4".
You have to have touched the field first, so that it is in focus.
Is that what you are asking for?
Calabash doesn't support it but you can use adb to press keyboard keys
adb shell input text "what%syou%want%stype"
In ruby you can execute terminal commands in a couple of ways but I use backticks
`adb shell input text "what%syou%want%stype"`
See here for more info - http://krazyrobot.com/2014/02/calabash-android-enter-text-from-keyboard-using-adb/
EDIT: Not too sure on the cause of the downvote but here's a bit more info on my answer in case it makes any more sense to anyone.
The equivalent function of keyboard_enter_text for calabash-android has the same name. It is in the TextHelpers module of calabash-android. To use it, you have to
require 'calabash-android/text_helpers'
However the implementation of keyboard_enter_text seems to be different behind the scenes for android in as far as it sets the text value in the field to the whole word/phrase like it has been pasted in, rather than with individual keypresses like it does for ios. As far as I know you can simulate the individual keypresses using adb commands if that is what you want.
I'm not sure why you would need to click on the keyboard buttons specifically, rather than just be happy that the text is in the field, as it is slower, but if you do for some reason then the adb commands should work.
Related
I mainly use vim as an editor for C/C++ programming. Unfortunately, I'm not quite satisfied with the way my build process works. I know that it's possible to type in (or map to a key) :make to run the make process. I dislike the way this command works, though, as it runs the build process in the same terminal window without proper highlighting. I therefore usually run the make command in another window on my second monitor so that I have both proper highlighting and can look at the build errors the compiler shows me in one window while scrolling through the source code in my main vim window. This is also quite tedious because it requires me to change focus to another window, then type in the make command.
Now, my question is as follows: Is it possible to make vim run the make command in this other window without having to change focus? This way, I could just map the "build in other window" command to some key in vim and could achieve all of this with a single key press.
My system is Manjaro Linux with i3 as DWM.
(I was unsure wether to post this on the unix forum or here, please forgive me if this is the wrong forum.)
You can achieve this by using xdotool and i3 config-file mappings. These mappings require that the last command executed in the terminal of the window rightwards was make.
set $prevR xdotool key --clearmodifiers --delay 2 super+l ctrl+p Return super+h
set $prevRclr xdotool key --clearmodifiers --delay 2 super+l ctrl+l ctrl+p Return super+h
And then map those commands to your preferred keys, for example:
bindsym --release Mod4+Shift+e exec --no-startup-id $prevR
bindsym --release Mod4+e exec --no-startup-id $prevRclr
The first mapping runs the previous command on the window right to the current one.
The second one does the same while first clearing the terminal. You need to substitute the super+[lh] with your own mappings that change the focus to your alternate monitor.
You may also have to increase the --delay to accommodate for the lag of changing windows.
If you also want to populate the quickfix list, you have to separately run :make in vim. By doing this you can both see the errors properly colored and formatted on your alternate monitor and be able to jump to the next error in vim with :cnext, :cprevious (see :help quickfix.txt for more info).
If you want to apply your make command to an arbitrary window, have a look at the
'WINDOW_STACK' section of the man page xdotool(1).
We've been struggling for a while now to understand the keyboard scancode behavior in Linux.
When we open a normal bash shell, the arrow keys works as expected: UP shows the previous item in the history etc. However when you spawn a process, arrows does not work as expected anymore. For example, UP prints ^[[A instead of the previous command.
To demonstrate this, do something like:
bash$ ping www.google.com
Now, press UP or DOWN etc. and you will see the wrongly mapped key codes while the process is running. However, when you terminate the process the arrow keys will work again.
We've tested it on CentOs, Ubuntu, Mac and even in different shells (bash, sh, zsh) and the same happens everywhere. I've also tried different keyboard modes using kbd_mode where we tested with RAW and XLATE modes.
The closest thing I could see while searching for answers were IPython users have experienced the same behavior when IPython was not build against readline. However, this is not related to our case as far as I can see.
We are developing a C++ Tcl based console application which uses cin and cout to communicate with, and get input from the user. We are having issues with the arrow keys when we try to access the history of previously entered commands. This is a major issue for us as 99% of people expects the arrow characters to just work.
Any ideas on how we could overcome this would be much appreciated.
You must set the terminal into raw mode to get the scan codes and handle them (that is: disable ICANON, you want the non-canonical mode). You probably also want to disable ECHO (so that it doesn't print your input on the terminal).
That is what readline or linenoise are doing. See here for some code. Esp. see the function linenoiseEnableRawMode. Some other simple sample Python code is here where I have written a simple console media player which checks for the keypresses left ("\x1b[D") and right ("\x1b[C").
The relevant calls are to tcgetattr (to get the current terminal state and modify that state struct to get into raw mode and enable some other useful behavior stuff) and tcsetattr (to set the state).
readline, libedit or linenoise are some libraries which do all that work for you and provide you with history, autocompletion, etc.
At the end, you must restore back the old state, otherwise you get the behavior you are describing in your shell.
First, a bit of background: I'm running the latest stable build of Crunchbang Linux inside a VirtualBox VM. I'm designing a custom text-based user interface to run on top of bash. This is being done with a combination of C++ and bash scripts.
I need to, at times, completely and totally remove the ability for the user to provide the system with any sort of standard keyboard input. This is because, when I run a part of the system, the user is forced to wait for certain amounts of time.
Unfortunately, the user can still type while this is going on, and whatever they type is put on the screen. This happens when I'm running a C++ program as well as a bash script. The reason this is a problem is that there is text on the screen which the user is to read, and if they can type, it displaces the text. There will be other uses for this later, as well, like making the system seem like it has frozen up.
So, the question - How do I
disable the keyboard, or
prevent anything pressed on the keyboard from showing up on the screen?
Turn off echo mode with stty -echo or the equivalent C code (which would use tcgetattr and tcsetattr). When you are ready to accept input again, turn it back on. You may also wish to discard the input that arrived while you weren't expecting it. That would be done with tcflush but be aware that some users (like me) would consider that an annoyance. Typeahead is a feature, not a bug!
To see how user input to a certain process or tty can be intercepted, the man page and source code of interceptty may be enlightening. (have no experience with it)
However, you can hardly (totally) prevent user input. The user is probably always able to switch to a different virtual terminal (if any) or at least to reboot the system with Alt+Print+B (Magic SysRq_key) if not disabled. It is two different things to ignore input on a given tty and disabling keyboard input altogether.
I was just debugging a program in gdb and somehow I found a new feature I've never seen or even heard of before, a split view where I can see and browse the code in addition to giving commands:
What is this? What did I do, or, more specifically, how can I get this split-screen mode again? Is there a name for this mode, or somewhere I can read about how to use it?
It's called the TUI (no kidding). Start for example with gdbtui or gdb -tui ...
Please also see this answer by Ciro Santilli. It wasn't available in 2012 to the best of my knowledge, but definitely worth a look.
You can trigger it dynamically by push ctrl+x and ctrl+a.
There are two variants of it.
to only see code Press
Press CTRL X together and then 1
To see both source and assembly
Press 'CTRL' 'X' together and then '2'
http://www.cs.fsu.edu/~baker/ada/gnat/html/gdb_23.html
A screen shot of the view with code and assembly.
Also check out this amazing Github project.
GDB Dashboard
https://github.com/cyrus-and/gdb-dashboard
GDB dashboard uses the official GDB Python API and prints the information that you want when GDB stops e.g. after a next, like the native display command.
Vs TUI:
more robust, as it just prints to stdout instead of putting the shell on a more magic curses state, e.g.:
vi mode in .inputrc causes problems: https://superuser.com/questions/180512/how-to-turn-off-gdb-tui/927728#927728
program stdout / stderr breaks your interface: GDB in TUI mode: how to deal with stderr's interaction with the ui
highly configurable from Python: you can select what you want to output and how big each section is depending on what you are debugging.
The most useful views are already implemented: source, assembly, registers, stack, memory, threads, expressions... but it should be easy to extend it with any information that is exposed on the GDB Python API.
TUI only allows showing two of source, assembly and registers and that is it. Unless you want to modify it's C source code of course ;-)
I believe that GDB should ship with a setup like that out of the box and turned on by default, it would attract much more users that way.
Oh, and the main developer, Andrea Cardaci, has been very responsive and awesome. Big kudos.
See also: How to highlight and color gdb output during interactive debugging?
You can also start it from the gdb shell using the command "-" (dash). Not sure how to dynamically turn it off though.
Type layout as a command in gdb and the split window will be shown.
When GDB is in the standard mode, using win will automatically switch in the TUI mode.
Other command for TUI mode:
info win
List and give the size of all displayed windows.
focus next | prev | src | asm | regs | split
Set the focus to the named window. This command allows to change the active window so that scrolling keys can be affected to another window.
Read here form more help.
There is also interface tool for GDB called cgdb. Even with some color highlighting.
"ESC" to switch to code view, "i" to switch back to gdb
tui mode was clearly inspired by emacs -- I discovered it by accident when I hit ^X-o, which switches among split windows in emacs -- I sometimes hit that absent-mindedly when what I should be doing is switching to a different program. Anyway, that leads to another feature not mentioned yet, that you can move the cursor from the code window (where you can scroll) to the command line, or vice versa, with ^X-o.
I'm looking to add an element to my wxWidgets GUI that behaves like a terminal emulator. Not in terms of a shell which executes commands, but just the input-output setup of an application running in a terminal.
Basically, the requirements are:
Streaming input/output: When you enter a character, it is added to an input stream, and when something is piped to the terminal, it prints out immediately.
No editing: Once you type in a character, it's permanently there, since it's probably been consumed by the application running in the terminal.
Some sort of scrolling (even if it just shows a few lines or something).
It would be nice if there is something that already does this, but suggestions on how to implement this with already existing controls such as wxTextCtrl would also be welcome.
I know this is a couple weeks late, but hopefully it's still useful. I've got a project called Chameleon that uses a wxWidgets-based VT100 terminal widget, which was itself based off of a project called taTelnet. The Chameleon source is available from my website (download page here). Not sure if it's exactly what you're looking for, but it might give you some ideas. Feel free to let me know if you have any questions about it.
wxWidgets supports redirecting STDOUT to a wxTextCtrl via wxStreamToTextRedirector. As for input, you could override the OnChar event in a wxTextCtrl-derived class to handle this.