NPAPI in MacOs gives me CGrafPtr in NPWindow structure, I need a WindowRef.
Is there a way to get WindowRef from CGrafPtr ?
Thanks!
NPAPI only gives you a CGrafPtr if you are using the very, very deprecated QuickDraw drawing model (with Carbon event model). Writing a new plugin using the QuickDraw model would be a terrible idea: Firefox 64-bit doesn't support it, Safari 64-bit doesn't support it, and Chrome doesn't really support it (and soon won't at all). Your plugin wouldn't work for most users.
Instead, you should be using either Core Animation (drawing) + Cocoa (event), or CoreGraphics + Cocoa. In the Cocoa event model there is, deliberately, no way to get a reference to the browser window. Modern browsers almost all run plugins in a separate process, and you can't reference windows across processes.
In short, if you are trying to make a new NPAPI plugin that requires access to the browser window, your design is wrong.
Related
I am in need to make a simple window in Go to display some text,
there is no need for a real GUI like interface.
How can I make a window like this using Go?
walk is the most common library used for basic GUI development.
You can import the package using:
go get github.com/lxn/walk
I assume you are working at windows OS so create an exe and run it.
More Information about this can be gathered from its source.
Visit https://github.com/lxn/walk
A nice-looking cross-platform UI can be created using HTML5/CSS/JS. You may open a native window with a full-screen browser engine (webview) in it showing your UI.
There is a tiny wrapper library for webviews on Windows, MacOS and Linux - https://github.com/zserge/webview
You can connectyour UI and the core app parts using Go-to-JS bindings (webview library provides those) or a websocket.
Apple's documentation suggests using WkWebView for new development, although it seems to have a typo where it recommends WKWebView over UIWebView in the mac developer library.
For new development, employ this class instead of the older UIWebView class.
The typo is probably because they are trying to unify the OSX and iOS interface to the web view by using the same header for both.
However, WKWebView doesn't have all the functionality that WebView has in OSX. For example, you can get access to DOM nodes in the native interface in WebView but I don't see any way of doing this from Swift/Objective-C in WKWebView.
For my purposes, it seems like WebView is what I need, but I'm weary of starting a project that relies on an API that will be removed. However, I don't see any mention of intent to deprecate WebView anywhere in the headers or the documentation.
What makes this even more confusing is the WebKit Framework Reference makes reference to both WK and older web view APIs without clarifying anything.
WKWebView
A WKWebView object displays interactive web content, such as for an in-app browser.
WebView
WebView is the core view class in the WebKit framework that manages interactions between the WebFrame and WebFrameView classes.
Is WebView going away in OSX?
Its not a false alarm. Apple moved Safari off of UIWebView/WebView in 6.0, so security fixes simply aren't happening in the old class as much. For that reason alone you should not use it for new stuff. Apple has been incrementally improving it with every OS release so much is now do-able with private extensions (file:// access, downloads, etc)
That being said, it won't be fully equivalent to old WebView. You can't directly access the DOM anymore because the Network/Rendering/UI processes were split up and you create locks by making element references like that. Use the postMessage() message handler and wkwebview.evaluateJavaScript() and callback-ish/promisy JS code between those two pillars to deal with web<>native interaction asynchronously.
Important
Starting in iOS 8.0 and OS X 10.10, use WKWebView to add web content to your app.
Do not use UIWebView or WebView.
https://developer.apple.com/documentation/webkit/wkwebview
I am using FireBreath 1.7 building a plugin for Safari 6 (and up) running on Mac OS X 10.8.5 (and up). The purpose of the plugin is to display video.
I have so far implemented support for CoreGraphics and CoreAnimation drawing models following the FireBreath example BasicMediaPlayer.
Performance is significantly better with CoreAnimation (which I implemented in OpenGL), and therefore my preferred choice.
The problem is that when using CoreAnimation, the plugin does not appear to honor the z-index, it just paints over everything. This is an issue because I would like to style my plugin video element (e.g. rounded borders).
I am aware of this post from 2012 (by one of the main authors of FireBreath), which basically confirms this being a limitation of CoreAnimation.
However, according to this article this should no longer be a limitation for NPAPI plugins in Safari 5 and up:
One caveat is that Safari 4, and Chrome up to at least Chrome 10, do not composite Core Animation plugins correctly. For those of you coming from a Windows or Linux NPAPI background, it's akin to windowed-mode plugins, drawing above all web content regardless of z-index. If that's deal-breaker, you'll need to use CoreGraphics and do a readback from an off-screen OpenGL buffer. Hopefully this will be fixed within a couple more releases of Chrome (it already works in Safari 5).
Which leads to my question: Does anyone know whether it is possible to achieve proper windowless behavior in FireBreath based plugins using CoreAnimation in newer Safari browsers on Mac?
We have a NPAPI internet plug-in, that is loaded from a certain web page (https). With the new Safari 7.0.2 it receives NPAPI_Destroy right after NPAPI_New call, failing the call of one of the exposed functions.
We do support core graphics drawing model and cocoa event handling model.
Our plugin doesn’t actually draw and doesn’t have a window. All that it does - to load an external application with the parameters, that are passed from the plugin.
In the html page it’s loaded as embed = from the java script.
We build it with universal 32/64 bit architecture. This problem started with the new version of Safari 7.0.2 on Mavericks 10.9.2.
Additional reload of the pages solves the problem and the plugin does its work.
Thanks in advance for any clues
Thanks in advance,
Nava
I recall reading about an application or library that allows to add some functionality to Cocoa apps.
I found it when searching for an application for using mouse gestures in Finder and applications other than browsers, but I didn't pay too much attention to it because I didn't know Objective-C or Cocoa at the time.
Do you have any idea of which one could it be?
Perhaps you're thinking of SIMBL?