How can I develop an installable desktop application on top of the Mozilla Engine or the Webkit engine.
We want to have best of both worlds, ease of development with DOM+Javascript+RenderingEngine+ContinuedImprovements in a Browser and user's control as in a desktop app
I looked at using C++ XPCOM for Mozilla but it seems to be quite complicated, Is there any other way to code like a WebApp using Javascript but burn it into the browser and dress it to give a feel of a desktop app. Also I require that javascript is compiled into native so that one cannot sneak into the source code
Are there any examples of desktop applications done this way ?
Web apps are fine but there are concerns of piracy, privacy, security and version control. The moot point is that in a web app the control lies with the software vendor, moreover the data is also with the vendor. Not only these, any changes to the application may also necessitate another around of training. What we want is that once the customer buys a version he is sure of what he owns and that he is in total control of it and we as software developer do not exposed our source code.
The issue is we have expertise in Web App development and we want to utilize that to develop a Desktop App
Your last point is that :
The issue is we have expertise in Web App development and we want to utilize that to develop a Desktop App
Well then BowLine can be an option though it requires Ruby, so you need to consider that. You can also take a look at WebKitDotNet if you are with .net Background.
Use XUL for the user interface and code your functions using JavaScript. You problably only need C++ to expose native functionality not yet available in Gecko. Examples of software that works this way: Komodo IDE, Songbird, Firefox and Thunderbird.
Related
I am trying to build a desktop app.
I am thinking of using electron on the recommendation of a web-developer friend of mine, but as I am the only sole developer, I don't have the means to test the software on different platforms(OS, hardware etc.).So I am anticipating that this will cause a problem later, in the end, to test/debug software on different platforms and different OS.
I have ruled out web-apps because of some privacy concerns of the users for the remote data hosting.
Software is pretty lightweight and is almost equivalent to the image viewer apps with some slight modifications.
How to solve the problem of variations of different platforms?
Any literature suggestions pointing me in the general direction are also welcome.
Sometimes it helps to think of Electron as two processes.
The renderer vs the main processes. Generally the renderer process which runs the HTML/CSS/JS is it's own isolated component, and you communicate to the main process using IPC.
So generally for the UI, you can use mostly any web based testing framework to test reliability. At Amna, for example, we use Cypress as our E2E testing platform. You an also use something like QAWolf. Both should work with localhost. In general, most website testing tools should work fine, and consistently across platforms.
Where this gets tricky is when a UI functionality makes a call to the OS or the main process. For example, saving to the disk, or launching a program.
The general flow is this, and I've yet to find radically simpler options:
Set-Up a VM or buy a machine with the corresponding OS. I used Spot VMs in Azure for this.
Manually test the scenarios you care about in each VM before you ship
If you have a lot of cases that rely on the OS, then you should be able to further optimize this by using an automated test runner like Spectron.
From experience, what I've realized is that most of the iterations I do happen more on the UI than the underlying functions with the cross-platform capabilities. And if your code has good separation (e.g. contextIsolation:true, nodeIntegration:false), it should be pretty obvious when you need to do an entire "cross-platform" test vs just UI tests.
I'm not familiar with a lot of large-scale electron testing frameworks, I do know that ToDesktop handles package building and generating binaries to perform a smoke test and verify things open across different operating systems.
It depends.
The answer depends on what you are building, so it makes sense to figure out what you actually want to build. Some questions you might ask yourself:
Do I need a database?
Do I need authentication?
Do I need portability?
Do I need speed to market?
Do I want to pick a language I'm familiar in?
These are all good questions and there are dozens more we all ask ourselves. However, back to your original question.
Electron is a fine choice
Yes, there are alternatives. But Electron is used for Visual Studio Code, Facebook Messenger, Microsoft Teams and Figma. Choosing Electron means there are other developers making apps and there are proven apps in the market so you don't have to worry about a dead ecosystem.
Electron is easy to onboard if you know web technologies, think js, html and css. If you know these, you can transfer your web dev knowledge and make a cross-platform app. You don't have to worry about learning each OS since the UI is the webpage which will look mostly* the same between each OS. (*some very minor differences, but essentially the same).
Cross-platform deployment is easy
There are a few ways of bringing your app to multiple platforms, I happen to be most familiar with electron-builder, but the other two solutions work as well.
Many templates to start with
I am biased, since I'm the author of secure-electron-template which is one of the many templates you can choose from when starting an app. However, I recently reviewed all Electron templates and found that only 4 do not have serious security vulnerabilities.
The Electron framework frequently is updated, and over the course of the past few years there has been a shift in the way Electron apps are made. Some earlier frameworks didn't have good secure defaults which some of the older Electron templates inherited and thus, aren't as secure as new frameworks that follow security guidelines.
If you decide on Electron, give my template a try. It's got a number of features I'm building out in order to help the community with features they might want (ie. internationalization (i18n), saving local data, custom context menus, page routing, e2e unit testing, and how one can use license key validation, to name a few things).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We are planning to built cross platform desktop application. We found that Node-Webkit is a perfect choice for us. But GitHub developed their own framework called Electron instead of using Node-Webkit.
What is the difference between them?
Electron has a page explaining the differences with nwjs.
Like NW.js, Electron provides a platform to write desktop applications
with web technologies. Both platforms enable developers to utilize
HTML, JavaScript, and Node.js. On the surface, they seem very similar.
There are however fundamental differences between the two projects
that make Electron a completely separate product from NW.js.
Entry of Application In NW.js, the main entry point of an
application can be an HTML web page. In that case, NW.js will open the
given entry point in a browser window.
In Electron, the entry point is always a JavaScript script. Instead of
providing a URL directly, you manually create a browser window and
load an HTML file using the API. You also need to listen to window
events to decide when to quit the application.
Electron works more like the Node.js runtime. Electron's APIs are
lower level so you can use it for browser testing in place of
PhantomJS.
Node Integration In NW.js, the Node integration in web pages
requires patching Chromium to work, while in Electron we chose a
different way to integrate the libuv loop with each platform's message
loop to avoid hacking Chromium. See the node_bindings code for how
that was done.
JavaScript Contexts If you are an experienced NW.js user, you
should be familiar with the concept of Node context and web context.
These concepts were invented because of how NW.js was implemented.
By using the multi-context feature of Node, Electron doesn't introduce
a new JavaScript context in web pages.
Note: NW.js has optionally supported multi-context since 0.13.
Legacy Support NW.js still offers a "legacy release" that supports
Windows XP. It doesn't receive security updates.
Given that hardware manufacturers, Microsoft, Chromium, and Node.js
haven't released even critical security updates for that system, we
have to warn you that using Windows XP is wildly insecure and outright
irresponsible.
However, we understand that requirements outside our wildest
imagination may exist, so if you're looking for something like
Electron that runs on Windows XP, the NW.js legacy release might be
the right fit for you.
Features There are numerous differences in the amount of supported
features. Electron has a bigger community, more production apps using
it, and a large amount of userland modules available on npm.
As an example, Electron has built-in support for automatic updates and
countless tools that make the creation of installers easier. As an
example in favor of NW.js, NW.js supports more Chrome.* APIs for the
development of Chrome Apps.
Naturally, we believe that Electron is the better platform for
polished production applications built with web technologies (like
Visual Studio Code, Slack, or Facebook Messenger); however, we want to
be fair to our web technology friends. If you have feature needs that
Electron does not meet, you might want to try NW.js.
Keep in mind this may be biased- it is from Electron's wiki page.
Electron doesn't introduce
a new JavaScript context in web pages.
Source code protection
Electron is packaging its applications with asar, which contains the applications' unprotected source code. This makes it possible for application 1 to extract application 2 and inject vulnerable scripts, without the user knowing it. You can checkout this project on GitHub to see an example of how to manipulate the Slack app for an example. As for now, the Electron team don't have any plans to implement support for source code protection.
NW.js has built in support for compiling your source code to protected binaries.
I am working on a Hybrid Application, targeting (for the moment) iOS. Does Worklight have a utility to handle application settings/preferences for iOS? I know how to write the native code to do this, but do not yet know how to gain access to the application settings from the JavaScript. Can anyone point me in the right direction or provide a working example?
In application-descriptor.xml, there is a worklightSettings flag you can set, however the settings page it creates is not user facing. That is, it is meant only for development time, or internal usage, and not production. It allows control of the server address that athe client connects to and change the web resources it will fetch.
So the answer is, no.
The mentioned settings page has set items in it that cannot be altered much (settings.bundle which does not allow much room for play. Maybe you could change it a bit, but doing so would void giving support to you if problems arise). I would recommend against doing so.
So this leaves you the option of creating this on your own. Maybe there is an existing Cordova plug-in that does something similar. Review these training modules of how to incorporate Cordova plug-ins to your application. Cordova bridges between JavaScript to native code, so it could be what you're looking for.
I spoke to the boss of a major music software company a few years ago. He told me that if they were going to start again from the ground up, they might look at WebKit for their UI. This totally surprised me. But I'm wondering if other folks are thinking and acting this way. Is webkit working its way in to truly non-web software?
RealPlayer, iTunes, and many other applications are using it, so are some non-"web" apps such as desktop widget programs:
http://trac.webkit.org/wiki/Applications%20using%20WebKit
Designing "web-apps" with HTML/Webkit UI is beneficial for Mobile users, since many devices have Webkit built in. Even if it is currently only used on a PC, you would have the possibility of hosting it on the web or local network later, with less work to convert it.
Gwibber, a Gnome twitter client that ships with Ubuntu, uses WebKit for displaying timelines (although it uses normal GTK+ widgets for the surrounding UI).
I would consider WebKit a viable option for many pieces of UI, particularly if the program shell exposes appropriate hooks into the surrounding platform to do things like launch a real browser or hook in to system notifications. You run the serious risk, however, of building an application that doesn't fit well in the UI conventions of the user's operating system.
It's not WebKit, but building a UI on a rendering engine is essentially what Mozilla does - Firefox, Thunderbird, etc. are built in XUL rendered with Gecko.
Anything you can do on webkit can be wrapped as an application easily with PhoneGap or other tools.
For example, store.sonyentertainmentnetwork.com could be wrapped as an OSX app, an Android app, and still act as a regular website very easily.
Also: https://products.sel.sony.com/opensource/source_webkit.shtml
I am writing a desktop app in VB.Net, and I'd like to include a web browser control to automate certain functions the user might have to perform in the browser. I have to render the page so I do not want to use the webrequest to make direct calls. When I publish the app, do I have to be concerned with which version of Internet Explorer the user has on their machine? Are their any third party, freely available, stable web browser controls available for VB.Net that people are using?
You could always ignore the whole IE issue and use the Mozilla engine embedded in your app:
geckofx
"An open-source component for
embedding Mozilla Gecko (Firefox) in
.NET applications."
http://code.google.com/p/geckofx/
Several versions of Visual Studio support web browser controls. Here is an article on how to implement one.
http://msdn.microsoft.com/en-us/library/system.windows.forms.webbrowser.aspx
The web browser control will work with different versions of Internet Explorer, but will be limited to the functionality supported by that version of Internet Explorer.
The article is based on Visual Studio 2008, but in the right corner of the article there are links, on how to use the web browser control, to earlier versions of Visual Studio.
If you embed the Webbrowser control in your application, what you're really doing is embedding a COM object. At runtime, your app will CoCreateInstance() the Webbrowser control, which will load it out of the version of SHDOCVW.DLL or IEFRAME.DLL that is currently on the machine. So, in plain English, you'll be getting the IE6, IE7 or IE8 Webbrowser control, depending on what is installed on the machine.
The practical differences, however, are minimal since the interfaces were published a long time ago and haven't changed over those versions. Differences in terms of different commands that some interfaces (such as IOleCommandTarget) support are abstracted away by the managed layer anyway, so you don't have to worry about that. The biggest difference will be rendering differences, since there is a huge delta in CSS conformance between IE6 and IE8. You'll have to test the various versions using Microsoft's app compat VHDs.
When I worked on the IE team application compatability wrt the Webbrowser control was a huge deal; the team works very hard to make sure that behavior doesn't regress for precisely this scenario—the custom enterprise VB app hosting the WebOC.
Though if you decide to go with an open-source solution to distribute with your app, may I suggest WebKit? Its layout engine is very good and the source code is pretty well maintained and easy to read, though you'll have to write your own managed hosting layer. The Gecko code is much harder to read and debug.