Embedded web browser engine for cross platform desktop application? [duplicate] - cross-platform

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How to embed a web browser control in a cross-platform application?
I'd like to embed a browsing engine (HTML,JS,CSS,DOM) in my desktop applications.
Which one is most suitable for me if I want to use it in a cross-platform desktop application?
Should I stick to one specific or write my own abstraction layer on top of the natives ones?
Update: A solution needs to provide an option for at least Windows/Mac/Linux.

WebKit is very lightweight and runs on all platforms. You will have to look at Google Chrome to see how to embed it into a Windows application. I believe it's native to GTK. There are also bindings for wxWidgets / wxPython.

Qt is highly optimised, cross-platform yet native-looking, usable from C++, Java and Python, and includes WebKit.

Awesomium might serve your needs-- it's a cross platform (Windows and Mac OSX) library based off of Google Chromium intended to help users embed a full-featured browser in their applications. It's free for non-commercial use and has a C++ API.

Should I ...
write my own abstraction layer on top
of the natives ones?
Having struggled with this exact issue, I think this is the only safe option at the moment. Something like Webkit on *nix, and Internet Explorer on Windows.

Related

Node-Webkit vs Electron [closed]

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.

PhoneGap for Windows Store Apps

Can we use PhoneGap for Windows Store Apps that will be developed using C# and Xaml? If so, can it handle all device and resolution dependencies?
I'm not quite sure what you're asking here. If the question is "Can we use phonegap to develop an app for windows 8" the answer is yes : http://docs.phonegap.com/en/edge/guide_platforms_win8_index.md.html#Windows%208%20Platform%20Guide
If you're question is "can I write code for a phonegap application using C#" the answer is no. The whole point of phonegap is that it allows you to write applications for various different platforms in HTML and Javascript.

Desktop Application upon Gecko/Mozilla or WebKit

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.

XUL used in web development

I am looking for some start up guidelines to share their experience on XUL development in web application. How good is the option to develop the interface in XUL ?. Can IE understand XUL interface?. I have started reading about XUL and I am liked confused a lot.
Please share your development experience on XUL development.
Thanks
XUL is a Mozilla-only technology meaning that it will only work in Firefox and other browsers based on the Gecko engine. I have bad news for you though: Firefox 4 (meaning Gecko 2.0) disabled support for remote XUL for security reasons, so using it in web applications will no longer be possible. It was arguably a bad idea in the first place.
Take a look into Ample SDK UI Framework, XUL (see examples) is just one of the several XML-based technologies it enables across all browsers, also in IE6.
The ZK web framework (www.zkoss.org) is based on XUL. Actually the web pages you built, using this framework, have the extension ZUL. It produces html + ajax code capable to run in all modern browsers. We are using it in my company for two years now and i have to say it changed my view about XUL.

Is WebKit gaining any traction in non-web applications?

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