Using XTERM control sequences (specifically CSI ?1000h), I can get notified on stdin any time the user clicks on the terminal window. Unfortunately this also means I get notified if the scroll wheel is spun, instead of normal terminal scrolling taking place. Is there any way to, preferably easily and simply, just get notified about clicks and nothing else?
Alternatively, is there a way to send an escape sequence that the terminal emulator will interpret as "oh, you want me to scroll normally"? I'd be (reluctantly) okay with having to parse all the mouse commands, and then if I notice a scroll-up signal (button 96 or 64 depending on mode), echo it back saying "here, terminal, you handle this one". In theory these should be the scroll-forw and scroll-back actions, but I haven't found a way to use these directly.
If it makes any difference, I'm using xfce4-terminal, but am willing to try other terminal emulators if it would help with debugging this.
The X10 protocol sends only clicks (no wheel mouse). That's documented. But that's for xterm.
VTE (checking just now with XFCE Terminal) differs from xterm by sending wheel-mouse events. VTE has no documentation worth mentioning, aside from its source-code (ymmv).
The scroll-forw and scroll-back actions are xterm features, for which there are no counterparts in VTE.
Related
As the title suggests, my touchpad won't move my mouse. I am therefore unable to select outputs of my commands, but I am able to take screenshots of windows. (Luckily I am used to using keyboard shortcuts)
I have no clue what caused this. I have recently updated my kernel from linux52 to linux53 and linux54. Falling back to either of those versions from linux54 hasn't helped. I have also recently been playing around with a Wacom tablet, using xsetwacom, but I believe my mouse has worked after this.
I know it's not a hardware issue, as libinput debug-events correctly detects my finger running over the trackpad:
The output of 40-libinput.conf in /usr/share/X11/xorg.conf.d/40-libinput.conf is the following. I can't see any error there.
I tried blacklisting the i2c_hid, as suggested in the following question, but to no avail. It fixed an error claiming there was a duplicate mouse, which it decided to ignore. I thought this would help.
What is surprising is that I can click. I can't scroll or move the mouse, though. My trackpad lists the following settings. To my surprise, there is no Accel Speed there, and I can't manually set it with xinput --set-prop 14 'libinput Accel Speed' 1.0, as I need to specify the type and format. I don't know what these are supposed to be, and I don't know if the acceleration is the issue. I read that having a negative value would cause the mouse to never move, though.
Do you have any suggestions as to what to do? What does libinput do with the events after receiving them?
EDIT: Removing the blacklist i2c_hid from the modprobe returns the following Xorg log:
Making a copy of /usr/share/X11/xorg.conf.d/70-synaptics.conf into my /etc/X11/xorg.conf.d/ folder, and commenting out the Option "Ignore" "on" line fixed it.
Had to sudo pkill X after changing it, of course. A reboot would also do the trick.
Requirements:
Our application replaces the usual windows shell (explorer.exe). This is a product requirement for a closed system that we're supplying.
We oughtta let the user select a wi-fi network and connect to it.
The problem: The wi-fi networks dialog only shows up when explorer.exe is running
What we tried:
Write our own wi-fi manager that uses wlan API. It lists connectible networks and allows the user to connect/disconnect. Problem: too many network types/configuratons that have to be tested, especially when the wheel has already been invented and reinvented all over.
Try and check how is the networks dialog implemented. It appears that it's and undocumented COM interface (IUIRAdioManager). Problem: it's undocumented, so no API
Use an existing network manager, for instance the one that comes with the driver. Problems: it's ugly, not to the product's taste; and it opens too many options for the user, like creating and loading profiles, browsing for files on a file system - these things are unacceptable.
Running explorer.exe just for the purpose of showing the networks dialog and then killing it. Problem: once we run explorer.exe - it pops up metro view and hides our fullscreen application or shows the taskbar.
The latter seems like the preferred solution: no need to reinvent the wheel, it does what's needed. Just gotta make explorer.exe not pop out, keep it quiet in the background.
So, we're down to two options:
How to show the networks flyout dialog without explorer.exe?
How to run explorer.exe without it popping out metro or taskbar above our application?
Your first solution would be incredibly difficult to implement. I am almost certain that the Networks window is dependent on explorer.
However, your second is entirely possible.
To hide the taskbar, you will need to find a window (using FindWindowEx) to find the taskbar (name is Shell_traywnd). This will hide the taskbar and start button. EDIT: Unless you are implementing your own taskbar, you might want to set the taskbar to autohide.
Next you will need to hide all of the metro programs. In a similar fashion as above, find the class named EdgeUiInputWndClass and close it. You should be able to get the process name of it and then kill the process.
Windows key. This is a little more difficult. You will probably need to use a program and delete the key or a keyboard hook (a low level keyboard hook) and just ignore key presses with the same scancode as the windows key. Left Windows is 0x5b and Right is 0x5c (source). Note that this will not block Ctrl+Alt+Del.
Finally, to show the Flyout, you can run %windir%\explorer.exe shell:::{38A98528-6CBF-4CA9-8DC0-B1E1D10F7B1B}
(source).
EDIT2:
You should also be able to hide toast notifications via this
Of course, I don't see why you cannot just use Windows 8/8.1 and put the app in kiosk mode.
I'm configuring GNU screen in a cygwin environment. Re-configuring actually--it always just worked before, and when I upgraded to cygwin-64 the same config files give me unexpected behavior.
What happens is that whenever I do something in the terminal that overflows a full screen the terminal does not scroll. Instead, each new line "overwrites" the last one on the bottom row of the window. Even when the process is through, if I CTRL+l, there's a bunch of garbage left on the last three lines of the terminal. Also, when I use a program that takes up the entire screen, such as vim or irssi, the "caption" line disappears.
I suspect that there's some discrepancy between my xterm settings and screen's 'term' setting, but I'm a little at sea here and, as I said, all the same configuration files worked fine (and do work fine on other machines--both cygwin and native linux). Can anyone recommend a way to get my beloved screen to behave again?
Here's my .screenrc:
shell /bin/bash
screen -t bash 0
select 0
escape ^Zz # Instead of Control-a, make the escape/command character be Control-z
autodetach on # Autodetach session on hangup instead of terminating screen completely
startup_message off # Turn off the splash screen
defscrollback 30000 # Use a 30000-line scrollback buffer
nethack on
# Misc h4x to make scrollback work
terminfo * te#:ti#
termcapinfo xterm|xterms|xs|rxvt ti=\E7\E[?47l
# Bells are annoying
bell_msg ''
vbell off
caption always '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %d/%m %{W}%c %{g}]'
You're running screen under xterm (something I do all the time myself). The screen process "knows" how big the terminal is, but that information can be out of sync with reality. I find this happens a lot when I run screen -dr from a different window.
Resizing the xterm windows causes it to send a SIGWINCH signal to the process running under it, which typically causes that process to re-query the tty settings.
Click the maximize button twice. If you're already maximized, that will restore it to a normal window and then re-maximize it; if it's not already maximized, it will do the opposite. In either case, it should cause screen to recompute the window size.
I encountered the same problem today. Thank everyone for the heads-up. The final solution I found out is that to set the mintty term type to: vt220. There must be something not right about the "xterm". After that, everything is good.
I'm answering my own question here because, while #Keith Thompson's answer does resolve the symptom of the problem, it didn't keep the symptom from occurring. He did set me on the right path, which was to install the xterm package in cygwin-64. That appears to have resolved the issue.
I downgraded screen version to Screen version 4.02.01 (GNU) 28-Apr-14 and it worked.
We have a hardware device, with an LCD display. It supports an USB interface to connect keyboard and mose. Using these keyboard and mouse, we can navigate to varios menu items and edit entries.
We have couple of test cases written to verify that mouse click and keyboard input events are working when pressed respective key.
My task is to automate these test cases.
I donot have any control to the hardware device, as I can not access the o/s kernel or any application running there. There is one way to verify what is currently displayed on the UI. So I have to use that and verify whether the mouse/keyboard has performed the appropriate events.
As I have gone through couple of previous posts, it seems like that one of the way to achieve this is through virual HID device driver rather than actual keyboard and mosue. But I am not sure how to achieve it.
Please do help me for it. I am fine with any programming language.
I am more interested to simulate the mouse and keyboard events.
You probably don't need to write your own driver. AutoHotKey does pretty much anything you can think of, and the scripting language is quite easy to learn.
You can get it here:
http://www.autohotkey.com/
Since you're using linux, here's a similar project that will run on linux:
http://sikuli.org/
Is there an SSH client that can present a client side GUI interface to the screen* program?
I'm thinking of an SSH program that would hook in with screen's session handling and map client side actions (clicking on a tab, ctrl-tab, scrolling, possibly even allowing several tabs to be seen at the same time) to whatever it takes to make screen at the other end do it's thing.
* The screen program that allow multiple virtual consoles under a single terminal session, for example you can run several apps under a single SSH connection and switch between them as well as other cool things.
An interesting idea, and quite possible (vim7's tabs show as clicky GUI tabs in gnome-terminal), but I don't see the benefit of doing this..
Using the follow ~/.screenrc shows "graphical" tabs:
startup_message off
vbell off
hardstatus alwayslastline
hardstatus string '%{gk}[ %{G}%H %{g}][%= %{wk}%?%-Lw%?%{=b kR}(%{W}%n*%f %t%?(%u)%?%{=b kR})%{= kw}%?%+Lw%?%?%= %{g}]%{=y C}[%d/%m %c]%{W}'
..which look like the following (after renaming the tabs using ctrl+a,a:
x http://img216.imageshack.us/img216/9401/picture4myi.png
You can scroll around in a screen session using "copy mode", by doing ctrl+a,[ and using the cursor keys (press Esc or ctrl+c to exit it)
You can also attach to the same screen session multiple times using the screen -x flag (rather than -r), so you could use any tabbed terminal emulator, and open one tab for each screen-window.
If you really did want to start implementing this - one option would be to look into modifying gnome-terminal, to copy the behaviour with vim's tabs for screen. Or, write your own screen client - you don't need to do anything as fragile sounding as scraping the terminal - there's a FIFO file in (usually) /tmp/uscreens/S-$USER/$PID.sessionname which I think is how screen communicates, and remember screen is open-source!
Interesting idea. I use screen everyday both on my local machine and for SSH sessions. I think your biggest problem is that I suspect most screen users are commandline junkies like me who just won't see the benefit of making a gui for tabs. In fact, I have all my terminals in one gnome-terminal window under different tabs, and having screen's text-based tabs is a nice way not to confuse the two.
I suspect it could be done, but you'd be writing a specialised terminal emulator which analyses screen's output (custom .screenrc) and retrofits the gui.
A lot of work for minimal gain.
ctrl+a shift+'
.. gui front-end to screen? what are you talking about??
also, because my rep is so low, and i cant comment, id like to LOL # geoffc for his comment in the question
I've never seen one, but the following may help you. Add to your .screenrc
To show a row of "tabs" on the bottom
caption always "%{.bW}%-Lw%{.rW}%n %t%{-}%+Lw %=%{..G} %{..Y} %m/%d"
To show the current program as the screen name [assuming you're using bash and your prompt ends with "$ " by default; others shells are the exact same idea]
shelltitle "$ |sh"