I am a novice when it comes to X windows but have some knowledge of Unix as such.
My project requires me to track user input and output on X window system. For instance, if the GUI is used to configure a route, I would like to know what application is used and what route has been configured. So far, I have explored the following options with partial success.
1)Tried to hook functions like XDrawString and XDrawText using LD_PRELOAD.
2)Used xwininfo to obtain window id and tools like xev.
3)Looked through similar discussions in this forum especially on xev and xinput
1)May not work with if X11 is statically linked? Not sure.
2)xev does not record key press events for a file edited with gedit or attempting to rename a file from the GUI
3)I am trying to go through X windows system internals.
I am pretty discouraged so far. Any input/pointer will be appreciated.
I think you want the cnee program from the Xnee project, which uses the X window system Record extension. The examples that I see for cnee are almost always about recording input events, but, according to the Xnee manual at https://xnee.files.wordpress.com/2012/10/xnee1.pdf, section 3.2.1 ("Record"), "Xnee can record the whole X11 protocol, not just mouse and keyboard events."
Regarding font operations, I believe that X font facilities, mostly through the X font server, evolved over time too, so it might be the case that the applications that you care about are doing X font operations which you can trace.
Related
I have a cross platform need to open a gui application programmatically, but keep it hidden from the user. Effectively, I want a command line driven interface to act as a wrapper over this gui app, and insulate the end user from seeing or interacting with it. The program is from a third party, I did not write it, and I can't edit it.
I can do this one way or another on Windows, on Linux, and (in theory) on older versions of Mac, but not the most recent ones. On Windows, I can use the native api ShellEx with a hide window parameter. It's very easy and straight forward. In Linux, I can can render a gui app to a virtual frame buffer (using xvfb).
On macOS, the open command has a --hide and --background option, but they don't have any effect (at least on this app...)
I tried changing the plist file and found that LSUIElement will hide the app from the docker, but it still shows up on the screen. LSUIPresentationMode=4 or 3 OUGHT to work for exactly this, but apparently that doesn't do anything anymore as of a few os versions ago...
I tried the approach of moving the .app off of the screen with AppleScript. That works, but you have to manually grant permissions for such a thing to occur via System Preferences. In prior versions of Mac, those permissions could be twiddled on the fly via sqlLite (so long as you had sudo rights), but now they blocked that too. You can only pull that off apparently through a process of disabling "SIP" and forcing a reboot. That is totally outside the realm of what I want.
I've tried using the xvfb approach on Mac (jumping through hoops to acquire the binary they use to include stock, and now dropped), but I'm not having luck with that. I don't think it's possible to direct a mac .app to another display is it? A .app does not render on X11 by it's nature right?
What other clever ways might there be to hide a third party app on a mac? (and that still works in most recent os versions!)
The end goal is to take touch input from an iOS device, send it over a websocket, accept it on the Mac OS X side, and send it through the system so everything using the private multitouch framework to accept input sees the data as if it were normal multitouch trackpad data.
The synthesize sub-project under https://github.com/calftrail/Touch seems like a good place to start. However it seems like the developer created it with the intent of taking valid multitouch input (from a magic mouse when there was arbitrarily little software support from Mac OS X), and piping it as multitouch trackpad input. I need to create valid/acceptable multitouch trackpad out of thin air (with just sequences of touch locations, not real HID data).
In deep here. Help, someone. :)
Glad you found my TouchSynthesis subproject — I think it will let you do what you need, since internally it is split up as you want it. [Please note however that this code is GPL licensed, i.e. virally open source, unlike many Mac libraries.]
You can treat TouchSynthesis.m as example code for using the TouchEvents "library" which provides support for your specific question via one "simple" function: tl_CGEventCreateFromGesture
The basic gist is that tl_CGEventCreateFromGesture takes in a dictionary of gesture+touch data and will return a CGEvent that you can inject via Quartz Event Services into the system. A gesture event is required to send what becomes NSTouch data, but IIRC could be a fairly generic "gesture" type rather than zoom/pan/etc.
This is sort of a halfway-private solution: Apple support injecting CGEvents into the system [at least outside The Sandbox? …I've since lost interest in their platforms so haven't researched that one…] so that part is "fine", but the actual CGEvent I create is of an undocumented type, the format for which I had to figure out via hex dumps and some Darwin source code HID headers they shared. It's that work that "TouchEvents.m" implements — that's how Sesamouse could "create valid/acceptable multitouch trackpad out of thin air" — and it should already be separate from the private framework MultitouchSupport stuff that read in the Magic Mouse input.
My Lenovo laptop has two task bar type programs that show the network status and battery status. I have been trying to search for what these types of widgits are called. Unfortuantly my google-foo is only returning results for minimizing programs to the system tray.
I am not even sure if these are system tray apps or taskbar apps. but either way, please help me find a API reference or even better a tutorial.
I want to make a Work Week Widgit, that displays the current work week number on this widget. I program mostly in python, but am willing to learn another language just to make this tool.
They are known as Desktop Bands, also known as DeskBands. Note that Desktop Bands are not recommended starting in Windows 7. Note also that since they are shell extensions, they must be written in native code.
I need to build an application on Mac OS X that runs on the background, windowless and provides a status icon in the top-right corner of the menu bar. It should launch on a specific action initiated by the user (not at system start up) and interact solely through the status bar icon.
On Windows this is very close to Services, on Unix - to daemons. What should i search for in Mac documentation? I just need a few keywords.
Nothing so strictly defined. Mac OS X considers the parts of your question to be separate concepts:
The icon on the right side of the menu bar (i.e., in the status bar) is a status item. Any application can create any number of them, using the NSStatusItem class.
An application with no Dock tile is usually an agent. An application with no UI at all is a daemon. A status item counts as UI, so an application with only a status item is an agent. The typical way to make an agent (with or without a status item) is to set LSUIElement to the string "1" in its Info.plist.
Having never programmed DOS or Windows, I have no idea what “resident” means to you. On Mac OS X, it simply means “in RAM”, which any running application at least partially is.
Services on Windows are not at all connected to this concept. A status item-only utility is the simile for something running solely from the system tray (like one of those delightfully useless nuggets that you get for seemingly every trackpad, audio card or GPU that you have the bad luck to be outfitted with). Services are just background programs a) without UI and b) that support or provide system or application functions. Dozens flare in and out of existence as you use Windows, mostly at startup, and most of them provide completely abstract functionality, such as providing network APIs for other services to use.
That said, Peter's answer is likely what you meant to find out, but I think it should be spelled out that it's not necessarily connected to the equivalent of Windows Services. (If you're looking to build such a thing on OS X, look up daemons and launchd.)
"launchd"
See http://en.wikipedia.org/wiki/Launchd
Mac OS X Leopard has a virtual desktop implementation called Spaces. I want to programatically detect which space the user is currently on.
Cocoa is preferable but AppleScript is acceptable if there's no other way.
I've seen a couple of AppleScript implementations, but the techniques they used seemed a bit too hacky to use in production code (one relied on causing an error and then parsing the error message to get the current space, the other interrogated the Spaces menu GUI)
Use HIWindowGetCGWindowID to get the CGWindowID for your WindowRef.
Use that ID with CGWindowListCreateDescriptionFromArray from CGWindow.h to get information on your window.
Look at the returned dictionary and extract the (optional) kCGWindowWorkspace key. That is your space ID for your window.
If anyone still cares, I've put together a little commandline util based on the answers here which you can get at http://github.com/shabble/osx-space-id