Is there a way to use the scroll mode in gnu/screen without blocking the running program?
With scroll mode, I mean the ctrl+a ESC key combination which allows you to navigate in the buffer with the arrow keys.
If that mode is active, the running program will be blocked when it wants to write to the terminal until you are finished.
I can modify the program that is being blocked, so a solution requiring change of the source code (instead of some screen settings) is alright as well.
Related
I want to disable / block the mouse click and keyboard typing for 6 seconds after launching a .exe file while displaying a advsplash.
Currently I manage to run a .exe file, activate the splash, block the keyboard and run a second .exe, but then, I need to restart the computer to unlock the mouse/keyboard.
Any idea on how to disable it without restarting the machine ?
This sounds like something you should never do.
If you want to do UI automation Windows already has support for that, using SendInput or keybd_event is not a good idea. Some apps steal foreground focus, this is just a fact and if that happens at the wrong time you end up sending input to the wrong window.
I have a third party application (I'll call it GreedyApp for brevity), which holds the mouse and keyboard input hostage when its window gets focus i.e. it hides the standard mouse cursor and replaces it with it's own cursor, and confines the cursor to its window. The only way to get input to other windows is to ALT+TAB away from GreedyApp.
I need to allow the user free use of all of the components of the system (the delivered system will be purely touch-screen), so at the minute the rest of the system becomes unusable once GreedyApp gets focus.
So far, I've hijacked user32.dll for GreedyApp, hooked SetCursor, ShowCursor and ClipCursor, and disabled them. The result is that GreedyApp no longer hides the cursor, and the cursor is free to roam wherever the user moves it, but...
The problem I'm left with, is that no matter where on the screen the cursor is pressed, or what keys on the keyboard are pressed (except ALT+TAB), the input is still directed into GreedyApp, and other windows don't receive any input.
I'm not sure how GreedyApp is achieving this, and therefore I don't yet know which API calls to hook to stop it. I though it might have been using hooks itself, but I've hooked and disabled SetWindowsHookEx, but the problem persists.
So my question is this:
Either:
A) Is there a (relatively straight-forward) way to find out what API calls an application is making at runtime?
or
B) What method is GreedyApp likely to be using to stop other windows from receiving input?
The application was using RegisterRawInputDevices to get raw mouse and keyboard input, and using the flag RIDEV_CAPTUREMOUSE to stop other applications getting focus.
I've hooked the API call and remove the flag before passing the parameters to the Windows API to process. The user now has control over the system :)
I reparent an external window into Qt application (XReparentWindow, XMapRaised, XMoveResizeWindow). It works, but when I click to that reparented window the system locks (no mouse or keyboard events), expect of may be some input inside the reparented window or may be my application.
Trying to embed, for example, gedit and clicking into it leads to keyboard events only in gedit (and even global Awesome's hotkeys disabled) and no mouse clicks anywhere (unless I close embedded gedit using Ctrl+Q).
The same if using QX11EmbedContainer. Even if do setEnabled(false) to it.
Why it locks up? How to prevent this lockup or how to disable input processing for some X window?
Reparenting a window into one own's application is covered by the XEmbed specification. If you read that spec, you'll see, that some additional work is to be done to make this work:
http://standards.freedesktop.org/xembed-spec/xembed-spec-latest.html
I'm trying to make an simple anti-idle script (that moves the mouse or whatever) to prevent an application from stopping.
How can I keep it running after screen lock ?
It seems like this is explained in the Autoit faq :
http://www.autoitscript.com/wiki/FAQ#Why_doesn.27t_my_script_work_on_a_locked_workstation.3F
On locked station any window will never be active (active is only dialog with text "Press Ctrl+Alt+Del") In Windows locked state applications runs hidden (behind that visible dialog) and haven't focus and active status.
So generally don't use Send() MouseClick() WinActivate() WinWaitActive() WinActive() etc.
Instead use ControlSend() ControlSetText() ControlClick() WinWait() WinExists() WinMenuSelectItem() etc. This way you may have your script resistive against another active windows. It's possible to run such script from scheduler on locked Windows station.
You can't automate anything after your screen is locked. User input is simply ignored. A much easier way would be to prevent your screen from locking, for example, by moving the mouse randomly every 30 seconds.
I read the following code in Unix Power Tools on page 117
*VT100.Translations: #override\
Button1 <Btn3Down>: select-end(primary,CUT_BUFFER0,CLIPBOARD)\n\
!Shift <Btn2Up>: insert-selection(CLIPBOARD)\n\
~Shift ~Ctrl ~Meta <Btn2Up>: insert-selection(primary,CUT_BUFFER0)
I have not managed to see any effect of the above code.
How can you use X clipboard in Screen, without your mouse?
Using the mouse. Left-click drag to select and usually the middle mouse button pastes but some terminals may differ (PuTTY uses right-click). If you only have two buttons you click them both together (left mouse button + right mouse button).
In reply to comment below ("Can you do it without your mouse?"):
ctrl-insert : copy
shift-insert : paste
shift-delete : cut
shift-ctrl-C : copy
shift-ctrl-V : paste
Not all applications will support the last three (though Konsole does). In fact most console applications will not allow you to delete text once it's printed.
As far as selecting text without a mouse I'm not sure there's a generic mechanism for that. It's probably terminal and/or application specific (ie, vim has it's own keys for marking and copying text - but only within vim). You could do it with mouse emulation but I'm sure that would be a painful process.
You can't use the traditional Mac/Windows shortcuts in a terminal because they were reserved for different actions long before these OS existed (ie, Ctrl-C terminates the running process).
I'm trying to use Ctrl-C in X
X does not handle these operations directly, they are handled by the application. That's why modern GUI programs like Firefox or Gedit support Ctrl-C for copy but terminals and command-line programs generally do not. As I said, it's a conflict in established conventions and Ctrl-C for kill got in first.
BTW, you could do some key-remapping if it drives you nuts but then you would be learning bad habits when you use a different machine. Best to just get used to it or do most of your editing in a GUI application.
More Information
EDIT: For a Mac, this may help: MacOSX-to-Konsole or This or This. It looks like you need to replace Ctrl with Command on Mac keyboards. It seems like Terminal the mac console has a right-click context menu for copy-paste so to do it the traditional way you me need to install a different console program or change some settings in Terminal.