I'm writing a Safari NPAPI plugin using CoreAnimationDrawingModel. This lets me create high performance CAOpenGLLayer and return it to the browser (I'm using this: https://wiki.mozilla.org/NPAPI:CoreAnimationDrawingModel).
Unfortunately, I'm having trouble supporting Retina displays in this setup because I cannot find a way of working out whether or not the plugin is hosted on a Retina display. Without this information I cannot set the CALayer's contentScale property properly.
In native applications I'd host the CALayer in an NSView and watch viewDidChangeBackingProperties to obtain the required resolution information. I'm not sure whether there is a way of obtaining the layer host in the NPAPI world? Even if that was possible, I'd be annoying to have to poll it for the resolution, ideally I'd want to register some kind of a notification listener.
I'm writing my plugin using FireBreath (http://www.firebreath.org/) and talked with the devs there (Richard Bateman) on IRC, but they suggested asking here (Stuart Morgan was mentioned as a good person to ask).
There's a spec for passing this information to NPAPI plugins. I'm not completely sure of the implementation status; Chrome doesn't implement it, casual inspection of Firefox source suggests it does, and since it was authored by an Apple engineer it's likely that Safari does.
Related
I've got a big ask here, but I am hoping someone might be able to help me. If there's another site you think this should be posted on, please let me know.
I'm the developer of the free app Amphetamine for macOS and I'm hoping to add a new feature to the app - keeping a Mac awake while in closed-display (clamshell) mode while not having a keyboard/mouse/power adapter/display connected to the Mac. I get requests to add this feature on an almost daily basis.
I've been working on a solution (and it's mostly ready) which uses a non-App Store helper app that must be download and installed separately. I could still go with that solution, but I want to explore one more option before pushing the separate app solution out to the world.
An Amphetamine user tipped me off that another app, AntiSleep can keep a Mac awake while in closed-display mode, while not meeting Apple's requirements. I've tested this claim, and it's true. After doing a bit of digging into how AntiSleep might be accomplishing this, I've come up with 2 possible theories so far (though there may be more to it):
In addition to the standard power assertion types, it looks like AntiSleep is using (a) private framework(s) to apply non-standard power assertions. The following non-standard power assertion types are active when AntiSleep is keeping a Mac awake: DenySystemSleep, UserIsActive, RequiresDisplayAudio, & InternalPreventDisplaySleep. I haven't been able to find much information on these power assertion types beyond what appears in IOPMLibPrivate.h. I'm not familiar at all with using private frameworks, but I assume I could theoretically add the IOPMLibPrivate header file to a project and then create these power assertion types. I understand that would likely result in an App Store review rejection for Amphetamine, of course. What about non-App Store apps? Would Apple notarize an app using this? Beyond that, could someone help me confirm that the only way to apply these non-standard power assertions is to use a private framework?
I suspect that AntiSleep may also be creating a virtual keyboard and mouse. Certainly, the idea of creating a virtual keyboard and mouse to get around Apple's requirement of having a keyboard and mouse connected to the Mac when using closed-display mode is an intriguing idea. After doing some searching, I found foohid. However, I ran into all kinds of errors trying to add and use the foohid files in a test project. Would someone be willing to take a look at the foohid project and help me understand whether it is theoretically possible to include this functionality in an App Store compatible app? I'm not asking for code help with that (yet). I'd just like some help determining whether it might be possible to do.
Thank you in advance for taking a look.
Would Apple notarize an app using this?
I haven't seen any issues with notarising code that uses private APIs. Currently, Apple only seems to use notarisation for scanning for inclusion of known malware.
Would someone be willing to take a look at the foohid project and help me understand whether it is theoretically possible to include this functionality in an App Store compatible app?
Taking a quick glance at the code of that project, it's clear it implements a kernel extension (kext). Those are not allowed on the App Store.
However, since macOS 10.15 Catalina, there's a new way to write HID drivers, using DriverKit. The idea is that the APIs are very similar to the kernel APIs, although I suspect it'll be a rewrite of the kext as a DriverKit driver, rather than a simple port.
DriverKit drivers are permitted to be included in App Store apps.
I don't know if a DriverKit based HID driver will solve your specific power management issue.
If you go with a DriverKit solution, this will only work on 10.15+.
I suspect that AntiSleep may also be creating a virtual keyboard and mouse.
I haven't looked at AntiSleep, but I do know that in addition to writing an outright HID driver, it's possible to generate HID events using user space APIs such as IOHIDPostEvent(). I don't know if those are allowed on the App Store, but as far as I'm aware, IOKitLib is generally fine.
It's possible you might be able to implement your virtual input device using those.
Is it possible to get icon for network computer/ip address under macOS so iMac has iMac icon etc?
I am using NSNetServiceBrowser to get available services, but I do not know how to get icon like official Finder app does. Finder recognize icons for iMac, MacBookPro etc. Thanks.
I don't have a working solution for you, but I see your question didn't get much attention yet so maybe I can point you in the right direction.
Finder looks for services, and it will check if found services have "device info" associated with them. This is done via Bonjour, looking for a _device-info._tcp pseudo service. A lookup for a device info may return a Bonjour TXT record that indicates the model ID of the gizmo. If Finder succeeds in getting this info, then it assigns an icon accordingly, otherwise, it picks a generic icon.
The icons themselves seem to be stored here: /System/Library/CoreServices/CoreTypes.bundle (at least on my 10.13 machine). Check the Info.plist on that bundle, and the other bundles contained within, and you can find mappings between device types and icons.
There are some posts talking about how to customise the icon that's shown for certain devices:
Add custom network device icons in Mac OS X Finder?
Can you use Bonjour for Windows to broadcast a different icon than the Bluescreen?
I tried to follow the steps in this post to examine the model names advertised by some Apple hardware on my network, but couldn't make it work (either using the dig tool or with NSNetService) (although I admit I didn't try very hard with NSNetService as I'm not familiar with it).
This thread discusses potential problems and solutions, however the dig tool wouldn't work for me despite having both SMB and AFP over TCP enabled.
All of these threads are fairly old, although the commentary in the linked SO post suggest this still works at least as of Sierra.
Good luck!
I've started playing around with Appcelerator Hyperloop. While it seems great to access native APIs from JS from day zero, it does raise a few questions about architecture of the platform and the performance.
Currently (AFAIK) a Titanium app has a main UI thread (that runs the native UI controllers) and a JS thread (that runs the JS logic). Each call from JS to Native is passed though the "Bridge" (which is the expansive operation in an app).
Also, Titanium API doesn't cover all the native API and abstracts as much as it can. But if new APIs are introduced it could take time for Appcelerator to implement those into the platform.
One of my favorite things about Titanium is the ability to extend it (using objective-c for iOS and java for Android) - allowing to use native APIs that are not covered by Titanium, and also developing a really native performance controls in case we need to do anything that's too "heavy" for JS. And, as mentioned it's developed 100% native for each platform.
Now that Appcelerator introduced Hyperloop I've done a simple test app and saw that Hyperloop is not translated into native code but just to normal JS code:
var UILabel = require('hyperloop/uikit/uilabel');
var label = new UILabel();
label.text = "HELLO WORLD!";
$.index.add(label);
And another thing about it is that you have to run on the main thread.
So we basically have a few things come to mind here as far as Hyperloop architecture goes:
We still have a bridge? if Hyperloop is JS that calls "special" Hyperloop require then we still have a bridge, that now not only acts as a bridge but also needs to do some sort of reflection (which is also an expansive operation)?
Until now JS ran in it's own thread - so now running in a single main thread seems to be a potential source to more UI blocking operation.
The old-fashioned modules were truly native (not including the bridge call) - so how do Hyperloop-enabled apps compare with those?
There isn't much documentation or articles about Hyperloop that explain the inner working yet - so if anyone has any answers have been trying apps with it could be very helpful.
Answering your questions straight-forward:
There are no Kroll-Proxies involved anymore, since actual classes are being generated on runtime. This is done by using the hyperloop-metabase that does reflection (as you already said) to build an AST that grabs the actual signatures, types, classes, methods, properties, etc.
We did not see any performance-issues with running on the main-thread for now. If you do so, please file a JIRA-ticket so we can investigate the use-case.
The old-modules were "less native" then now, simply because they were all wrapped by the Kroll-proxy (by extending every view from TiUIView and every proxy from TiProxy / TiViewProxy. Hyperloop does not work with those, making the module-development much more faster by also allowing the developer to test his/her process live in their app without the need of packaging and referencing the module manually. Hyperloop modules are nothing else then CommonJS modules that are already used frequently across Alloy and other Ti-components.
I hope that gives you a quick overview on how Hyperloop works. If you have further questions, let us know!
Hans
(As a detailed answer to the above comment)
So let's say you have a tableview in iOS. The native class is UITableView and the Titanium-API is Ti.UI.TableView / Ti.UI.ListView.
While the ListView already provides a huge performance-boost compared to the TableView by abstracting the Child-API usage to templates, those child-API's (Ti.UI.Label, Ti.UI.ImageView, ...) are still custom classes that are wrapped and provide custom logic (!) e.g. keeping track of it's parent-references, internal data-structures and locks to jump between the threads.
If you now check the Hyperloop example of a native UITableView, you access the native API's directly, so no proxy behind it needs to manage sections, templates, items etc. Of course we deliver that API through a kroll proxy in order to display it in Titanium, but you don't "jump between the bridge" with every call you make from the SDK.
The easiest way to see that is to actually run some bigger example like the tableview, collectionview and view-animation. If you do a fast scroll through these, you already feel the performance boost compared to "classic" Titanium API's, simply because the only communication between your proxy and (like a Ti.UI.Window you want to add it to) is the .add() to receive the native API of the type HyperloopClass.
Finally, of course it still makes sense to use Ti.UI.ListView for example, because it comes with the builtin utilities that Titanium devs love (events, easy configuration and layout-handling). But thats also where the benefit of Hyperloop comes along, by allowing the developer to access those API's him-/herself.
I hope that helps a bit more to understand it.
I have a desktop app based on HTML/JS that needs WebKit to function at a reasonable speed. Normally, I would live with IE behaving badly, but its JS engine is just too slow.
I would normally go to Appcelerator for this, but it seems they have discontinued their desktop SDK and left it for the "community"...
This needs to function on Windows PCs, or I would just use Fluid (http://fluidapp.com)...
Is there a simple Webkit wrapper that I can use, or should I build one really quick in something like Qt. I haven't used Qt in a while, so I'd have to look at it again and make sure WebKit is implemented in it...
While it is somewhat node.js-oriented, AppJS may offer what you're looking for. If it doesn't already support other scripting languages, it might at least provide a good example to start from.
Update: in the time that's passed since my original answer, it seems node-webkit fills a similar role but has gathered and maintained more momentum than AppJS. It's a little more focused, in that it doesn't attempt to provide much additional "framework" on top of simply exposing the node.js API to the window's JS context.
There's also https://github.com/atom/atom-shell, which I just learned of and may be similar.
One other thing to note is that (presumably with either, but at least with node-webkit), you MUST be cautious of any XSS-like vulnerability in your app that an attacker could exploit to gain complete access to the user's native machine. So if you are simply needing to package an offline web app in a downloadable desktop distribution, you may wish to research more PhoneGap-like solutions (e.g. Mac OS X as PhoneGap platform) or a plain web view wrapper (like mentioned in the OP) that do not expose an entire OS-level native API — as node.js does — into the JavaScript environment.
I've been thinking to give GUI development a try lately and am torn with the choice of between wxPython and Mono.
Judging from what I've seen out there, wxPython people seem to use the WebKit trick to produce nice (doesn't have to be beautiful) UI.
How hard is it to do the following in each of the platform:
1) Custom Control
2) Use HTML rendering
I don't quite understand how far the HTML rendering works via WebKit in wxPython (i.e.: does it support separate CSS/JS files? how's the JS support? do we need to write extra wxPython code to run the JS? how hard it is to integrate between JS events and wxPython widgets? what are the usual strategy of integrating WebKit with wxPython?)
Mind to share your thought on this subject? I specifically pick either wxPython or Mono, not Java Swing for no reason.
PS: I'm aware of certain limitation of cross-platform UI (as in: it won't be 100% native) and I could care less of such things.
wxPython has wxWebkit available via the new WebView widget, but WebKit is only available on Mac and Linux right now. WebView uses a different rendering engine on Windows called Trident from IE (see http://wxpython.org/CHANGES.html). So you'll want to keep that in mind.
Either way, we're talking about browser engines that display HTML, CSS, etc. They should, theoretically, display whatever those engines support. You'll have to look up their specifications to be sure and also make sure to check if the port supports everything. As I understand it, they should definitely support the usual HTML and CSS and I would assume normal javascript. If I were you, I'd just create a simple window in wxPython and then load the web page you've created and see how it works.
I don't know how the javascript communicates with wxPython or if it even does. You'll want to ask on their mailing list for that kind of information.