There have been posts in various places over the last few years about WebVR in Electron, and the answer has always been (very reasonably) that it is not a core part of Chromium and so not supported in Electron.
However, WebXR is now a core part of Chromium. As long as you have an OpenXR installation Chromium runs WebXR with no need for special command line options or flags. However, the versions of Electron based on these versions of Chromium still do not allow XR. navigator.xr is present, but attempts to get a webXR session always fail. Is there any information about when we can hope for WebXR support?
This is probably better as a feature request or question for the Electron community, not StackOverflow. My guess is that although WebXR APIs might be part of Chromium now, the underlying OpenXR integration is still up to the project that uses Chromium. So you're really just seeing the stubs of the API, not the actual implementation itself.
Related
I'm trying to get a number of Chrome extensions working in an Electron app. Electron only supports dev tools extensions, so I'm writing code to handle regular extensions more-or-less from scratch. But, I'm getting stuck figuring out what's involved in getting the content scripts to run in the same way they do in Chrome.
In the existing Electron implementation, which is expressly limited to development tool extensions, I traced the code to here, specifically, line 392:
win.devToolsWebContents.executeJavaScript(Extensions.extensionServer._addExtension(${JSON.stringify(extensionInfo)}))
Finding the next step in this process has proved very challenging. I think, but am not certain, that HERE is the corresponding Chromium code, but this seems like it's for development tools extensions in particular (what with the calls to InspectorFrontendHost and the use of iframes).
Could anyone point me in the right direction? Where is the code where Chromium loads the content scripts for regular extensions? Or is this that code?
I have found so many facility to use javascript, Angular, material design ui with Electron App Framework, I would like to know, is there any possibilities to use ANT UI for my desktop application? At-least some work around.
Yes
The short answer is yes. Electron provides an entire NodeJS environment and allows you to use common Node, Javascript and React toolsets.
In fact, Electron is listed as an officially supported environment on their Github page.
That being said, it's a very diverse library so there might be occurrences where a particular component is not supported or might need tweaking to be compatible with the Electron environment.
Update
The company I work for actually had to do this for a project we're working on so I can officially confirm that it works great.
What browsers is supported by stable Dart 1.1.1 - where can I find such information or results of tests done on browsers. I want be sure what I can except in future version.
It is not clear for me what mean "major browsers" since it is not clear if it is tested. I plan to use dart since can be nice in doing advanced application.
I think only about compatibility of Dart/JavaScript - not interested in pure Dart in Chromium.
From the Dart FAQ:
Q. What browsers do you support as JavaScript compilation targets?
We’re currently aiming to support the following browsers:
Internet Explorer, versions 9 and 10.
Firefox, latest version.
Chrome, latest version.
Safari for desktop, version 6.
Though "We're currently aiming to support" certainly doesn't inspire the same level of confidence that "We support" would.
It's not really an answer but to long for a comment:
Dartium is intended for development only.
JavaScript generated from Dart is currently the only supported scenario of Dart for production use.
Dart or more specific the generated JS helps a lot in abstracting browser differences away but there are also still a lot of open issues, some with known workarounds and some without.
I doubt there can or will be a perfect solution even in the future.
How good or bad someone finds the support of one of the browsers listed in #PixelElephant s answer is mostly based on opinion and/or what features someone wants to use.
If you have issues with some of these browsers, post an issue. Common features are likely to be fixed in the short therm others may take longer (also depending on complexity).
I'm working on a software that includes 3D graphics. Those are massive enough, so I decided to use OpenGL to keep a quite fluent animation. I selected THREE.js graphic library (WebGL).
Reading the html through a Web browser works very well : WebGL functions are recognized. I did it on my desktop (Win32/Firefox17, please do not judge me on my configuration !) and on a Nexus 10 (Android 4.3, FF24 and FF25Beta, tried with Chrome30Beta but no joy...). But I need to access native data, like the file system, to get informations for my program. So I wrapped my code with WL, and deployed it as an app on my Nexus 10... And so disappeared the WebGL capability... :(
So I looked for a reason to that :
I found on the IBM site two different ideas : in one way, I understand that a JS engine is embedded, in another that WL uses the engine of the default Web browser of the tablet (what I understood the first time)...
Let's be precise with the different engines : On the Nexus, FFs have obviously Gecko engines, Chrome30 is a Blink (webkit-like, version 537.36). Those are the ones detected by window.navigator.useragent as I read directly in the browser, no surprise. In the Eclipse/WL preview, I got different interpreters, depending the browser I selected, FF or IE (not Safari, I don't have it installed), but not the one from my desktop (the ones used are even older than my own FF...). But, when I detect the one used in the app (after wrapping in an apk), it returns an AppleWebkit 534.30/Worklight/6.0...
Maybe I'm wrong (tell me), but if 'Worklight' is in the version of the engine, and if webkit is used even when I suppress Chrome from my tablet (the version is different, but who knows..), I wonder that, for this app, as it's configured, the engine is embedded by Cordova or WL.
If it is so, I agree it allows to read a code with a fully-compatible interpreter, regardless the browser installed on the hardware. But when a webkit engine does not please you for the functions it supports (like WebGL, very partially supported), it looks a problem for me.
Does anybody have a confirmation of how it works ? If the engine is wrapped with the app, do you know if we can choose the one to be included, or configure it (like enabling WebGL ;) ) ? Another idea ?
Thanks,
Vincent.
Worklight applications do not bundle an interpreter. The application will use what that is bundled in the OS.
In other words, the default WebView in Worklight is the one that the OS provides, in the case of Android it uses the bundled WebKit.
This is not something Worklight controls what-so-ever.
You could, maybe, somehow, bundle in your app the Firefox engine libraries and hook it all up together, but the task to do so is incredibly large and complex in size... and not supported by IBM Worklight. Also, I do not know whether Cordova supports this as well ( it is used in Worklight to interface with native functionality).
As for the useragent, the string "Worklight" is attached to it as part of support for IBM WebSphere Portal.
Background info:
Over the past week, I have been messing around with Chrome extensions and had no problem creating my extension. Great, Chrome rocks for making the development process very easy to learn, and, well... just easy!
Now I have it in my mind that I'd like to create this extension for as many browsers as I can, so I decided on Firefox next.
What a mess! There documentation has done nothing but give me a headache and waste my time so far, VERY convoluted and just generally unorganized.
I have managed to locate a code sample for a simple extension that I think I can use as a starting point and have begun messing around with - fine...
I have learned that this sample extension will not work with anything less than Firefox 4, as it uses the bootstrap technique to make the extension installable without a browser restart. Ughhhhhh....
Now we arrive at my questions:
Is it possible to develop an extension for Firefox 7 that will work with previous versions of Firefox? I don't even care about anything prior to Firefox 4, if that's the cutoff point for restart-less installations. It would be nice to know that what I am spending all this time making will work consistently and for more than a week when the user is prompted to upgrade next.
How about the reverse? Can I create an extension that is compatible with Firefox 3.5 through Firefox 7? I realize it would require a restart to install, but that would be acceptable if it resulted in a working extension regardless of the version.
Can anyone with experience on this stuff share a bit of what I'm getting myself into here? It seems like this is a nightmare of a platform to develop on, and that I will be constantly fixing my extension.
One last piece of relevant information:
The extension I am developing is purely javascript based - this stuff should work (I think?) because it's dependent on just one feature "content scripts" that really shouldn't be changing in implementation between versions at this point... right?
So what exactly am I missing? How do you create easily manageable Firefox extensions that will work in all versions of the browser?
Thanks everyone! :)
You have to distinguish between "traditional" extensions and extensions built with the Add-on SDK. The former are far more powerful given that they have direct access to all APIs the browser uses - but that's also the reason why they are more complicated to write and why the documentation is rather unordered (there are simply very many things that you could do, far more than you could with Chrome). They are also more likely to break as the browser changes. The Add-on SDK on the other hand gives you a limited API much like Chrome. The Add-on SDK currently supports everything from Firefox 4 onwards (yes, because of restartless installation), with the promise that browser changes will merely require your add-on to be recompiled with a newer version of the Add-on SDK. In fact, that recompiling will likely happen automatically in future for add-ons hosted on addons.mozilla.org. On to your questions:
Is it possible to develop an extension for Firefox 7 that will work with previous versions of Firefox?
Sure it is. The Add-on SDK currently marks your add-on as compatible with anything between Firefox 4 Beta 7 and Firefox 8 Alpha 1. Even as traditional add-ons go - starting with Firefox 4 the differences between particular browser versions are rather small, most things work in all of them. You can also stay compatible with Firefox 3.x but depending on what you do it might require some effort. Important information:
Firefox 4 for developers
Firefox 5 for developers
Firefox 6 for developers
Firefox 7 for developers
How about the reverse? Can I create an extension that is compatible with Firefox 3.5 through Firefox 7?
It doesn't matter which way you go. I wouldn't recommend spending much time on Firefox 3.x support however. With Firefox 3.5 no longer supported the only relevant version is Firefox 3.6. According to the statistics of my add-ons roughly 18% of the Firefox users continue using it. In the next few months this percentage will get significantly smaller, especially when Mozilla announces end-of-life for this branch. So for a new add-on supporting it is usually not justified.
Can anyone with experience on this stuff share a bit of what I'm getting myself into here?
Depends on how complicated your add-on will be. Given that you are developing an equivalent to a Chrome extension, you will most likely be using the Add-on SDK which means that there won't be any compatibility problems. As traditional add-ons go, simple add-ons that don't rely on some obscure implementation details also typically don't have any trouble staying compatible (I have two add-ons that didn't need a single adjustment since Firefox 3.5). Add-ons that go deep down into the system are more problematic of course.