goal: is to collect information about user interactive program in Tracking app.
most efficient way is through process ID. the only way i can think of is getting Xlib Window associated process ID, does other ways around?
going through documentation, and source code, no clue for Window associated process ID attribute, maybe Xlib doesn't keep PID, or does it?
non efficient solution is through Window name attribute.
Xlib doesn't keep process ids - it was designed to work on a variety of OS'es with different process abstractions, and across networks, where a pid on one machine isn't very useful on another machine.
But since most X applications today are being run on Unix-like machines and displayed locally, not over the network, many modern toolkits adopted a convention of storing the process id in a property on the window of that application. See the _NET_WM_PID section of the Extended Window Manager Hints specification for details.
The X server doesn't have that information. In fact, there may not even be a PID available -- clients can connect to an X server over the network.
If all you need to do is identify what program is being used, though, you could look at the WM_CLASS window property. This property contains a pair of strings that are used to identify the window to the window manager, and usually includes the name of the application.
Related
Let's say, I have chrome running, which has 100 different processeses, not all of which are direct children. What's the best way to programmatically get all of the processes from either the procfs or the any syscall may be (I believe getrusage only allows calling process), given the PID of the main chrome parent in the hierarchy?
Also, is there any API that's equivalent to PSAPI in Windows which provides OpenProcess, GetProcessMemoryInfo etc, that allows you to iterate through memory efficiently, rather than parsing the procfs?
Most efficient way please. No calling other processes like ps, pstree, pgrep, etc.
Side context: This is mostly an educational exercise to find the most efficient way to do this, which I started going down trying to write a simple script in nodejs to try and get all the processes programatically and then, calculate the sum of the memory taken by the process tree, including each.
I'm actually the author of a C++ library that is designed to do exactly that - pfs.
pfs attempts to make all the interesting information inside procfs accessible through a very simple API. If you find it lacking any useful information, please create an issue, and I'll try to add it.
Seeing that you require that information from Node.js, you might be able to use the library for "inspiration" or for research purposes (as in, understand where the information is located).
Regarding the process tree: The procfs contains the parent PID of every process (find it under stat and/or status). You can enumerate all the running processes and store them into a container and then iterate over it while drawing or retaining the order you require.
I am trying to setup my processes so that certain bots/resources can and can't run them. I can see a capability drop down, but I don't know how to limit the capabilities.
I am almost certain that the capability feature is not complete yet and it's something that will make its appearance in the following BP versions.
As far as I can think of, you could either take advantage of some of the Multi-team environment functions and hide some resources or processes for some groups of people, or you could use the GetResourceName() function to terminate your process if not executed on the white-listed machines.
Not ideal, we'll just have to see what the capabilities are about.
I'm writing a linux application using C++ and wxWidgets.
From my application, I need to send keyboard events to the window that currently has the focus (not belonging to my application!).
My questions are:
How can I find out what window has the focus?
How can I send a keyboard event to a window not belonging to my application?
Thanks
Daniele
XGetInputFocus(3).
X11 does not care about "applications". There are only windows. It's enough to have a window ID (Window is the Xlib data type). Use whatever method of sending events works. There are two methods I know of: XSendEvent(3) and XTestFakeKeyEvent(3). The former method does not work with some programs that chose to ignore events coming from XSendEvent. The latter one requires the XTest extension, which is present in most, but not all, modern servers.
Note that InputFocus is a valid window designator for XSendEvent, and XTestFakeKeyEvent is delivered to the window that has the focus anyway, so you probably don't need to call XGetInputFocus at all.
If you use 2.9, you can use wxUIActionSimulator. It is intended to work with other windows of the same (wxWidgets) application but AFAICS it should actually work with the windows of other applications when using X11 too (however I didn't test it myself).
I have always read and worked off a single UI thread since having more than one will screw up message pumping etc etc.
I am answering my own question here but want to validate my understanding on Chrome browser which is known to have multiple processes ( one per tab ) - does it also accelerate some bit on the rendering part by employing multiple UI threads ?
My guess is it does NOT , but if it does It would be very interesting to know or look at some sample c# code to demo the same ( does not have to be web browser demo).
Any pointers in the multiple UI thread direction would help! thanks.
I cant state definitively how Chrome handles the rendering threads - but I would assume that each tab has its own rendering thread. I wouldnt see the point of going through all the effort of process isolating the tabs, only to tie them all together on a common rendering thread. They would all have the opportunity to interfere with each other.
I implemented a 'chrome-style' browser using WPF - the application shell was a single process, then each 'tab' was a MAF AddIn running in a separate process. The rendering was all in child processes - there was nothing shared. Each AddIn returned an INativeHandleContract (a WPF control) which was passed across the process boundary.
The upshot of this, was that an exception ANYWHERE in a child tab, would only take down the tab, and could be detected by the parent process, giving it a chance to provide some feedback/reload the tab etc.
This document wasnt around when I achieved it, but after a quick browse I think it has some pointers:
http://msdn.microsoft.com/en-us/library/bb909794.aspx
Kent Boogaart also lent a helpful hand
http://kentb.blogspot.com/2008/06/maf-gymnastics-service-provider.html
You may also need this QFE from Microsoft to fix a bug in serialization you may experience when passing a WPF control across a process boundary:
http://archive.msdn.microsoft.com/KB982638
In regards to MS Connect bug: https://connect.microsoft.com/VisualStudio/feedback/details/467381/wpf-controls-cannot-be-passed-across-process-boundaries
Don't confuse threads and processes. Each process will have it's own ui thread, but likely also it's own message pump.
I would like to hook into, intercept, and generate keyboard (make/break) events under Linux before they get delivered to any application. More precisely, I want to detect patterns in the key event stream and be able to discard/insert events into the stream depending on the detected patterns.
I've seen some related questions on SO, but:
either they only deal with how to get at the key events (key loggers etc.), and not how to manipulate the propagation of them (they only listen, but don't intercept/generate).
or they use passive/active grabs in X (read more on that below).
A Small DSL
I explain the problem below, but to make it a bit more compact and understandable, first a small DSL definition.
A_: for make (press) key A
A^: for break (release) key A
A^->[C_,C^,U_,U^]: on A^ send a make/break combo for C and then U further down the processing chain (and finally to the application). If there is no -> then there's nothing sent (but internal state might be modified to detect subsequent events).
$X: execute an arbitrary action. This can be sending some configurable key event sequence (maybe something like C-x C-s for emacs), or execute a function. If I can only send key events, that would be enough, as I can then further process these in a window manager depending on which application is active.
Problem Description
Ok, so with this notation, here are the patterns I want to detect and what events I want to pass on down the processing chain.
A_, A^->[A_,A^]: expl. see above, note that the send happens on A^.
A_, B_, A^->[A_,A^], B^->[B_,B^]: basically the same as 1. but overlapping events don't change the processing flow.
A_, B_, B^->[$X], A^: if there was a complete make/break of a key (B) while another key was held (A), X is executed (see above), and the break of A is discarded.
(it's in principle a simple statemachine implemented over key events, which can generate (multiple) key events as output).
Additional Notes
The solution has to work at typing speed.
Consumers of the modified key event stream run under X on Linux (consoles, browsers, editors, etc.).
Only keyboard events influence the processing (no mouse etc.)
Matching can happen on keysyms (a bit easier), or keycodes (a bit harder). With the latter, I will just have to read in the mapping to translate from code to keysym.
If possible, I'd prefer a solution that works with both USB keyboards as well as inside a virtual machine (could be a problem if working at the driver layer, other layers should be ok).
I'm pretty open about the implementation language.
Possible Solutions and Questions
So the basic question is how to implement this.
I have implemented a solution in a window manager using passive grabs (XGrabKey) and XSendEvent. Unfortunately passive grabs don't work in this case as they don't capture correctly B^ in the second pattern above. The reason is that the converted grab ends on A^ and is not continued to B^. A new grab is converted to capture B if still held but only after ~1 sec. Otherwise a plain B^ is sent to the application. This can be verified with xev.
I could convert my implementation to use an active grab (XGrabKeyboard), but I'm not sure about the effect on other applications if the window manager has an active grab on the keyboard all the time. X documentation refers to active grabs as being intrusive and designed for short term use. If someone has experience with this and there are no major drawbacks with longterm active grabs, then I'd consider this a solution.
I'm willing to look at other layers of key event processing besides window managers (which operate as X clients). Keyboard drivers or mappings are a possibility as long as I can solve the above problem with them. This also implies that the solution doesn't have to be a separate application. I'm perfectly fine to have a driver or kernel module do this for me. Be aware though that I have never done any kernel or driver programming, so I would appreciate some good resources.
Thanks for any pointers!
Use XInput2 to make device(keyboard) floating, then monitor KeyPress and KeyRelease event on the device, using XTest to regenerate KeyPress & KeyRelease event.