If I wanted to write my own window manager for OS X (please dont respond with "whats the point"??), what APIs should I be looking at?
There is no such thing as a "window manager" in OS X, and no public interface to implement one. The functions that an X11 window manager would perform are split between the GUI toolkit (Carbon/Cocoa), the Dock application and the window server.
Your only real choice if you want to change OS X's windowing behavior is to patch individual applications, the Dock (which has a privileged connection to the window server) and/or the window server. It'd involve a great deal of reverse engineering and almost certainly break in 10.6, but it's certainly possible.
At the hardware level, write your own APIs.
Otherwise, there are various graphics architectures in which to plug in your window manager:
OpenGL
Quartz
Quicktime
X11
Related
In Windows VCL, I have the TTrayIcon to be able to (partially) hide my application. Is there a similar method to have an application being outside the normal task list on MacOS and only accessible in an alternate location normally reserved for background applications?
The specifics is a TCP/IP server listening on a port for incoming traffic, but one that doesn't need a UI interface (except for setup purposes). On Windows, I manage this with TTrayIcon and a TPopupMenu, but I am at a loss on how to implement similar functionality on MacOS.
What you are looking for is called Menu Bar app for Mac OSX. A search for "macos menu bar app source code" will yield lots of examples, but I have only found one (partial?) example written in Delphi. The main API to use is NSStatusItem.
EDIT: There is an example statusitem.pas for Lazarus / Free Pascal which might be useful for your purposes.
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.
I want a small functionality for all my Mac OSX application windows. When I double click on the title bar, either nothing happens or the application will get minimised(if the appropriate option is checked) instead, I want to create a functionality where it will get maximised completely(not full screen).
I am assuming that I should write a daemon for this but I am quite new to coding.
So my question is:
Can my "goal" be achieved by a daemon?
No, it cannot. There is no way to implement this functionality with public APIs on Mac OS X.
Is there anything similar to GetForegroundWindow on Mac OS X?
I've two apps one windowed (NSDocument based) and one command line I want to show an NSOpenPanel from command line tool and would like to make it model for the NSDocument based app but don't have the windowref for it?
There are a few problems with what you want.
First of all, applications on the Mac do not have window references. An application may have any number of windows. Second, access to other processes' windows is limited in Mac OS X. There are a few APIs for accessing them in different ways. At any rate, having a reference to another app's window will not allow you to throw up modal dialogs for that application.
What you want is to have the command line app communicate with the foreground app to tell it to show the open panel. You could either establish your own communications protocol (e.g. through Distributed Objects) or you could use Apple Events/AppleScript to communicate back and forth.
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