Is there any way to track the process(get PID), which is writing to or reading from X11 clipboard ?
Related
When closing spacemacs with SPC q s or SPC q q. Often the emacs GUI will display the message "Saving Clipboard to X Clipboard Manager". Then it will not close.
Interestingly, this does not occur when using terminal emacs emacs -nw.
The clipboard on my os is Xfce Clipman. I'm thinking perhaps the emacs is assuming there is a different clipboard and performing an inappropriate operation.
I'm not sure how to debug this, because emacs is frozen when this is happening. Any suggestions as to how I can resolve this issue?
not responding while saving clipboard
Had this same issue. As seen in the Emacs documentation, you can stop this by disabling interaction with the clipboard manager.
(setq x-select-enable-clipboard-manager nil)
I'm dipping my feet into Cocoa for the first time.
Here's a simple question. OS X Lion supports Resuming of window state when an app is terminated and relaunched. Okay, good and fine.
But for document-based apps, can the same Resume feature also manage saving of window state when a document is closed and reopened later but without any quitting of the app? (In other words, can it manage each file's state persistently regardless of whether the app quits or not? Or do I have to manage it myself by saving the information in the documents' files?)
For instance, iWork '09 apps do do this sort of thing: if you close a saved document and reopen it, it will restore the window size, location, and scroller position. I don't know if it does this using Lion's Resume per se.
But, in contrast, OS X Lion's TextEdit restores windows when it is quit and restarted, but it does not remember window states when you close a document and reopen it. This makes me suspicious that using Resume without quitting might not be possible automatically (since maybe Pages keeps window states in its proprietary file format, but TextEdit doesn't since it uses plain text, RTF, HTML, etc. files).
I don't have access to the WWDC 2011 videos yet, and neither the OS X release notes, the OS X Application Programming Guide, nor the NSWindowRestoration API docs talk about this specifically.
So the question again: automatically remembering the state of a document window after closing and reopening it without quitting the app (like iWork does)...does Lion's Restore support this?
Thanks a lot!
But for document-based apps, can the same Resume feature also manage saving of window state when a document is closed and reopened later but without any quitting of the app? (In other words, can it manage each file's state persistently regardless of whether the app quits or not?
Not unassisted, no.
Or do I have to manage it myself by saving the information in the documents' files?)
Or somewhere else, yes.
My untested suggestion is to try using the window-restoration protocol yourself. When closing, send yourself encodeRestorableStateWithCoder:, then stash that data in your document (or wherever you want). When opening a document, if it has restorable state information, pass it to restoreStateWithCoder:.
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'm developing an app and I'd like to trigger functions in my app via keystroke combos when it's not in focus.
Because I'm developing my app in AIR, I do not have access to listen to global Keystrokes. However, I can receive STDOUT from an application. So, I'm looking for a utility that can give me this ability. I'm looking for both Windows and OSX (cross-platform baby!)
For Windows, you could write a simple application that installs a keyboard hook and prints information about the key event to stdout. See SetWindowsHookEx.
For Windows:
I don't know of any app off the top of my head, but here are some ideas that might work within 100 lines of code...
I would avoid SetWindowsHook, as that would inject your code into all apps. (Because I've spent good time debugging crash dumps and bugs as a result of poorly written hooks...)
You could write a console app with DirectInput (old gaming keyboard API). I believe you just pass DISCL_BACKGROUND and DISCL_NONEXCLUSIVE into IDirectInputDevice8::SetCooperativeLevel call. Use IDirectInputDevice8::SetEventNotification to set the event handle so you don't have get into a busy wait loop polling for input. And that should do it. I did this once for my app a long time ago on Windows 98 and it worked really well. But DirectInput is very close to being deprecated technology so YMMV.
Another simple hacked up way to do what you are doing is to have your app create a hidden window, call call RegisterHotkey for all the keyboard, and pump window messages. Your wndproc will get a WM_HOTKEY window message that you can use that to generate a message to stdout.
The simplest way, but will be slightly error prone and cpu-expensive is to have your console app get into a loop and call GetKeyboardState. This will return the entire state of the keyboard of all keys that are up and down. You'll have to figure out how translate each poll into a logical keystroke. I'd recommend sleeping a few milliseconds between polls so you don't kill system-wide performance.
Can't help you on OSX.
For windows, here is a utility that will listen to the keyboard.
http://www.dynamicnetservices.com/~will/academic/textinput/keycapture/
I am using xvkdb with X11 to send the content of my Barcode reader to the Keyboard Focus Window.
But I am looking to port this Barcode Reader on Microsoft Windows. How would you do that?
Here is the bash script :
zbarstream /dev/video | xvkbd -file -
If you just want to copy text, use the clipboard. There are many command line utilities that allow you to copy text to the clipboard. I use my own, very simple 5-lines Delphi pascal. You can find such a utility in Raymond Chen blog the new old thing http://blogs.msdn.com/oldnewthing/archive/2009/11/10/9919908.aspx
This method provides an additional safety that is the user must paste the text into the application, but this additional required action may be undesirable. In that case, or if you need more detailed control, then you need some way to inject keystrokes into the keyboard driver. There are some keyboard simulators and keyboard automation utilities. AutoIT and AutoHK are very popular.
AFAIK, the On-Screen Keyboard included in Windows doesn't have a command-line interface and therefore doesn't support input redirection. I'm not sure about other third-party virtual keyboards as I have never used any.
However, there's the SendKeys scripting method that can be used to simulate keyboard input into the active window. So if you launch your Barcode Reader and capture its output from a script (VBScript/JScript), you should be able to use SendKeys to send that output to the active window.