I was reading the documentation recently and got stuck on this part.
From http://developer.chrome.com/apps/app.window.html#type-CreateWindowOptions
transparentBackground ( optional boolean )
Enable window background transparency. Only supported in ash. Requires experimental API permission.
Soo... What is Ash? ;)
"Ash (the Aura SHell) is the ChromeOS window manager"
"Aura is the hardware accelerated UI framework built on CC."
- From a chromium-dev email Explainer: Aura and Ash #defines & dependencies
Also, see a block diagram of Aura and dependencies.
It means the feature is available only in ChromeOS.
Related
I'm using a GUI application framework (EGT) on an ATMEL/ Microchip SAMA5D4. The framework features
DRM/KMS and X11 backends.
I've looked at using tslib to calibrate a restive touchscreen for the device but due to EGT limitations it looks like I'm going to have to use libinput for the moment.
Is there a calibration mechanism (equivalent of tslib) available for libinput? I've looked at xlibinput_calibrator & it seems like it could be a solution but I'll have to sort out the dependencies in the Yocto build.
Thanks,
For anyone looking at this xlibinput_calibrator looks like it requires X11 & was not an option.
I eventually ended up using a startup script to prevent EGT capturing raw events (deleted /dev/event0 or similiar) from the touchscreen & instead use the calibrated source from ts_input.
In the Python GitHub documentation i see reference to ManagedGateway, however, unlike the Java documentation on Watson IOT site, the Python docs doesn't have any reference for firmware update.
Does the Python package supports Firmware update for Gateways?, or all must be done through the Notification function or by using a ManagedDevice ?
#Yarh We are working on this functionality. However, check the
ibmiotf.gateway.ManagedClient class, that provides ManagedGateway functionality.
In case that one does not address your requirements, please elaborate the requirement.
Is there someway to determine the Chrome platform version in order to verify that I can use APIs that are marked v37 and later? If there is an alternative way of verifying that these new parameters are supported by the current install that works as well. My current solution is to check for the existence of a different v37 API which seems to be working, however if there is a sanctioned way that would make me feel a bit better about the whole thing :).
I need to use the 'scopes' portion of this API:
chrome.identity.getAuthToken.
In its Cog Chrome App, François Beaufort is using userAgent with a regex to get the chrome version:
window.alert(
navigator.userAgent.match('Chrome/([0-9]*\.[0-9]*\.[0-9]*\.[0-9]*)')[1]
);
But there is maybe a better way to check if some html/js API are available or not...
Try adding a minimum version to your manifest, so you don't even have to check in your code. This will prevent the app from webstore installs who are on older versions.
"minimum_chrome_version": "37",
Is there any API/SDK to support tts (text to speech) in Marmalade?
I've had some success porting Flite (http://www.speech.cs.cmu.edu/flite/) to the Marmalade environment. It produces wave files and raw, in-memory buffers (which can then be played using s3eSound directly) fine.
The s3eSound adapter (which plays the text directly from within flite) is a work in progress, so, while it does produce something close to recognisable speech, it is also obviously bugged. For my purposes, the raw buffers are more useful anyway, but feel free to try to fix it up.
You can see what I've done here https://github.com/madmaw/marmalade-flite
There is no specific API provided by Marmalade however you may be able to use the EDK if native APIs provide this functionality on iOS or Android.
https://www.madewithmarmalade.com/devnet/docs#/main/extensions.html
I'm creating an NPAPI plugin that isn't supposed to have a UI (for use from Javascript only). What windowing model should I use (windowed/windowless/xembed) to support as many browsers (and browser versions) as possible?
I currently implement the following functions:
NPP_SetWindow: do nothing, return NPERR_NO_ERROR
NPP_Event: do nothing, return kNPEventNotHandled (0)
NPP_SetValue: do nothing, return NPERR_NO_ERROR
NPP_GetValue: if asked for NPPVpluginNeedsXEmbed, answer yes if the browser supports it (NPNVSupportsXEmbedBool), no otherwise
For this plugin I am supporting Linux & Windows only for now. The NPPVpluginNeedsXEmbed was necessary for Chrome on Linux (bug 38229), however some old versions may not support it as the MDC page says that the sample plugin for XEmbed is only supported on Firefox 2.0+.
The most common that I have seen is to not care at all about the windowing mode and set the object tag to 1x1 (you can try 0x0, but I've seen browser bugs related to that) size, in which case it doesn't really matter what window mode you use. However, I would do windowless myself since it won't ever cause the trademark block that floats over all other DOM elements that a normal windowed (XEmbed or not) plugin gives you.
This is what FireBreath does if the FB_GUI_DISABLED flag is set.