Is it possible to get the pointer or the window number of the underlying NSWindow of a JComponent on Mac, using JNA. I found methods getWindowID and getWindowPointer in com.sun.jna.Native. The documentation mentions getWindowID is for X11 and getWindowPointer is for win32. Is there a similar function for Mac OSX ?? I know how to get the cocoa window of a component using a JNI function but I am interested in using something in Java without writing a JNI function.
-Thanks,
Abhinay.
If you know how to do it in jni, then you most probably can do it with JNA. But, you would have to create your own mapping to cocoa libraries or see if rococoa already has what you need.
getWindowPointer() does the same thing for Mac OSX (it returns a pointer corresponding to the cocoa view ref). You may have to do additional manipulations to get a reference to the exact reference you need; as Denis suggests, rococoa likely has some utilities that would provide useful.
Related
I have a program on windows that manages OpenGL contexts, (things such as making them current, destroying them, pretty much everything but the actual creation). I've recently moved to programming on a mac, and I was wondering if there is some function similar to wglGetCurrentContext for OSX. I can't seem to find the documentation for these online.
Edit: The AGL (Apple GL) framework and more specifically the function aglGetCurrentContext are all deprecated.
You are looking for CGL (Core OpenGL).
The equivalent of wglGetCurrentContext() is CGLGetCurrentContext(). It works similarly.
There's the OpenGL Programming Guide for Mac, but I found the CGL reference to be rather more useful. I was unable to locate the CGL reference on Apple's website, but there's a mirror.
I'm running Lazarus Pascal (1.4.2, FPC 2.6.4) on a Intel Mac OS X (10.10) and would like my application window to be visible on all virtual desktops (Spaces). How can I achieve this?
I'm using the Carbon widget set, as the Cocoa widget set is still in early stages of development.
Note: I realize this question is very similar to this StackOverflow question, however that question is geared towards Objective-C. I have no clue how (in Carbon) to use the code suggestion. Mostly because it is Cocoa specific, but also because I have no idea how to link this behavior to my TForm - if that is even possible.
You can use method setCollectionBehavior: of NSWindow with the
NSWindowCollectionBehaviorCanJoinAllSpaces bitwise flag.
Since I can apply the "All Desktop" option in Finder, when I have multiple virtual desktops/spaces, maybe there is an alternative to set this outside of the application? (i.e. something like using "defaults" in Terminal)
wxWindowMac::MacVisibilityChanged() is virtual method and it is meant to be overridden, but it does not get called in Cocoa, while when using Carbon it was. (There was a migration from Carbon to Cocao).
My guess is that triggering this method via events is not implemented for Cocoa port of wxWidgets. Anyone had the same problem, what was the solution?
I am using wxWidgets 3.0.2 and Mac OS 10.9.
Found the answer myself for this one.
Just add an event handler for wxShowEvent and forget about using wxWindowMac::MacVisibilityChanged.
I read this advice:
How do I use Qt and SDL together?
and now I have question connected to it. This example was created for Linux, but how use it under Windows? winId() under Windows return WinAPI Handler for widgets, other then Linux. Is there any possibility to use SDL under Windows with Qt?
Yes.
Both of them are portable frameworks and tools. I think there is no huge problem but maybe there is some easy compilation issues.
Note: winId() returns OS-specific value such as HWND for Windows, HIView for Mac and Window for X.
Returns the window system identifier of the widget.
Portable in principle, but if you use it you are probably about to do
something non-portable. Be careful.
If a widget is non-native (alien) and winId() is invoked on it, that
widget will be provided a native handle.
On Mac OS X, the type returned depends on which framework Qt was
linked against. If Qt is using Carbon, the {WId} is actually an
HIViewRef. If Qt is using Cocoa, {WId} is a pointer to an NSView.
I'm quite new to the Mac but reasonably expirienced with windows.
What I need is a window owned opened and closed by the library (dylib).
This is very easy to do in MS Windows but seems not be hard under Cocoa.
I used the code from apple's 'CocoaInCarbon' example with C++ Wrappers.
But the NSApplicationLoad() followed by [NSBundle LoadNibNamed:#"MyWindow" owner:self] fails. Is this caused by the dylib not being a bundle.
Are there alternative ways to open and control a window within a dylib?
Yes, the problem is that it's not a bundle; your nib can't possibly be inside a bundle that doesn't exist, so how would the code find it to open it?
You need to either use a framework (which is a bundle), and ship the nib in that framework, or you need to create the entire window programmatically in your dylib.
It's not a standard practice to just ship dylib on Mac, when the shared library is not very low level and involves GUI in particular. You package it into a framework, so that it can not only have codes in it, but associated resources (nibs, images, sounds) in one place.
Read this Apple document to understand what's going on and how to prepare it. Or, take a look at /System/Library/Frameworks/ to see how the OS X itself provides libraries.