Re: inter process NSView sharing
Re: inter process NSView sharing
- Subject: Re: inter process NSView sharing
- From: Ken Thomases <email@hidden>
- Date: Fri, 23 May 2008 12:05:34 -0500
On May 23, 2008, at 10:14 AM, Jonathan Cochrane wrote:
ive just had a look at 'son of a grab' source and it seems there is
the
concept of a CGWindowID, maybe this is what i need ?
below is an excerpt from the NSWindow Class Reference:
These constants and data type represent the access levels other
processes
can have to a window's content.
typedef enum {
NSWindowSharingNone
<http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/doc/c_ref/NSWindowSharingNone
>
= 0,
NSWindowSharingReadOnly
<http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/doc/c_ref/NSWindowSharingReadOnly
>
= 1,
NSWindowSharingReadWrite
<http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/doc/c_ref/NSWindowSharingReadWrite
>
= 2
};
typedef NSUInteger NSWindowSharingType;
NSWindowSharingReadWrite
The window's contents can be read and modified by another process.
Available in Mac OS X v10.5 and later.
Declared in NSWindow.h
If a process is not allowed to draw in another process's window on
OS X,
have i misunderstood the concept of NSWindowSharingType ?
Those declarations are indeed intriguing and tantalizing. However, I
don't know of any supported way to make use of them the way you want.
Maybe it's planned for the future. There's some additional stuff like
that in /System/Library/Frameworks/ApplicationServices.framework/
Frameworks/CoreGraphics.framework/Headers/CGWindow.h. In particular,
CGWindowSharingType seems like the Core Graphics equivalent of that
Cocoa enum.
A CGWindowID is documented there as being valid across the user
session. However, I don't know of any way to create a Carbon or Cocoa
window from a CGWindowID. The HIToolbox Release Notes for Mac OS X
10.5 includes this, though:
The HIWindowGetCGWindowID API has been added to allow access to the
window server's global window identifier for a WindowRef. This
number is not usable with any other Carbon APIs, but may be passed
to other APIs that do take window numbers, such as OpenGL.
Oooh, that's quite close! Unfortunately, I can't see where OpenGL
could take a window number.
Now, I am familiar with a completely different approach to this.
Apple provides a special library for implementing X11 and allowing
direct GL rendering by an X11 client into windows owned by the X11
server, provided they're both running on the same machine. That
library is /usr/lib/libXplugin.dylib. It's only documentation is its
header file /usr/lib/Xplugin.h. It also provides windows which
require a lot more manual handling than anything provided by Carbon,
Cocoa, or Java.
Truthfully, I recommend you avoid this whole hassle until Apple
provides complete support for what you're trying to do. Instead, I
suggest that you refactor your app to avoid the need for one process
to draw into a window created by another. Can you host your C code
inside your Java program? Or, replace what is currently a Java front-
end (I'm guessing) with a Cocoa front-end, and then have your C code
be that program's back-end?
Good luck,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden