5

In Java there is a notion of "rich client platform" - it's a framework for building desktop applications, provides common features like help browser, window layout management, etc. Prominent frameworks are Eclipse and Netbeans.

Now I am curious if something like that can be done on top of web browser? I heard about XULRunner, Chrome extensions, NPAPI and such but hesitant to dive further (my current idea is to fork Chromium).

Basically, is there a way from a (serverless) browser application:

  1. Work with filesystem (Open/Save/open OS file browser)
  2. Start OS processes (e.g. some utilities) and parse their output.
  3. Access dynamic libraries.
  4. Alter browser UI (e.g. remove home/address bar, redo menus)
  5. Package as something easily deployed throw the app stores.

Can this be done without forking the browser? What should I read about?

Updated Requirements: Essentially I am looking for "PhoneGap for PCs" - but I really like how I could reuse Chromium UI (tabs, preferences, etc) if I forked it. I'm prototyping on Mac, will setup a Linux build. I am not interested in Windows at this point...

Eugene
  • 656
  • 4
  • 10
  • 1
    1 and 2 would both be *major* security holes in any browser if they could be performed by code running on a page, and simply aren't going to be options. As for 5, the whole *point* of a browser is that you don't *need* to go through a deployment process, you just host it on the web and there is no deployment to a client needed. – Servy Aug 12 '13 at 16:54
  • @Servy Yes, I understand that those would be security holes - but I'm pretty sure I can still do it from the NPAPI plugin. But installing NPAPI (and uninstalling) seems untidy. Re: 5 - I am not looking for "web application" - I am looking to build desktop application using web technologies, kinda like doing mobile apps with PhoneGap. – Eugene Aug 12 '13 at 17:02
  • Does this application _have_ to be serverless? What about creating an app that is a small special-purpose server that runs on the local machine? You can build your UI in the browser and talk to this server for filesystem access. – Bryan Oakley Aug 12 '13 at 17:20
  • The browser is a desktop application and designed, by its very nature, to isolate your desktop from the rest of the world. You would be reinventing a lot of wheels to use it as local platform, hence making it into something it is designed not to be. Have you checked out ChromeOS and/or FireFoxOS? – Jerry Gagnon Aug 12 '13 at 17:33
  • @BryanOakley I am currently looking at "serverless" as a means to reduce latency (I admit that I do not know if latency would actually be a problem - it's my assumption) and for ease of deployment. – Eugene Aug 12 '13 at 17:41
  • @JerryGagnon It's not as much a browser that I am interested it as the HTML/CSS/JS rendering component. – Eugene Aug 12 '13 at 17:42
  • 1
    @Eugene There are pleanty of desktop UI platforms capable of rendering HTML/CSS/JS within their UI component. Having an emulated browser within a rich client desktop app is quite feasible, having a rich client desktop app within a browser is not. – Servy Aug 12 '13 at 17:48
  • @Servy - That's what I am trying to confirm/disprove :) This is just another small research project because I hate the state of these Java frameworks, believe Qt to be horribly ugly and not willing to do completely native UIs. – Eugene Aug 12 '13 at 18:35
  • 2
    @Eugene This is why you should ask about what you want to do (define a desktop UI in html/css) rather than how you think it should be done (create a rich client that runs entirely within a browser). Your *real* question is quite solvable, by a number of frameworks. The question you asked is answerable, but the answer (of it's not possible) doesn't help you. – Servy Aug 12 '13 at 18:37

3 Answers3

6

You probably want the Chromium Embedded Framework, which is apparently used by a fair number of high profile applications.

The Chromium Embedded Framework (CEF) is an open source framework for embedding a web browser control based on Google Chrome, it is a convenient way to implement an HTML 5 based GUI in a desktop application or to provide browser capabilities to an application. It comes with bindings for C, C++, Delphi, Java, .NET, Python and runs on Linux, Mac OS X and Windows. (wikipedia)

From the sound of it, you could write the bulk of your application in HTML+JavaScript+CSS, relying on some "host" language to provide access to system resources.

Another option, particularly if your target is non-Windows platforms, is to actually write a web application that either rests on apache or comes with a simple web server, like PHP's built-in web server. Launching the application, in the latter case, would be a matter of invoking both server component and the browser (after the server component picks a port to listen on).

If your target platform were Windows, the concept of a trusted HTML Application has been around for quite awhile. You'd basically write an HTML page (including javascript, vb script, and styling), give it a .hta extension, and it would operate like a trusted application.

http://en.wikipedia.org/wiki/HTML_Application

From there, you'd be able to access Windows Script Host functionality.

That said, if your target environment is Windows, it's probably easier to just build your application with C# in Visual Studio, which is available in an "Express" (free) version.

svidgen
  • 13,414
  • 2
  • 34
  • 60
3

If I'm correct about your plan to make a desktop application, and not actually use the browser itself all that much, then Awesomium or a similar framework may interest you. You're still coding the back-end stuff in C#/C++, or whatever language you prefer, but your UI (the strength of HTML/CSS) can be coded using web technologies.

Also, if you don't mind reducing your target audience to 1/10th, Windows 8 lets you code apps using HTML/CSS/JS.

Katana314
  • 862
  • 1
  • 5
  • 18
  • Thank you. Awesomium looks quite fitting my purpose, though I am not sure if I can release a product under open-source license based on it. – Eugene Aug 12 '13 at 17:39
  • There's often a lot of confusion over what can be done commercially/not, making use of open-source tools. I can't answer those questions for you, but be sure to look over Awesomium's licensing FAQ: http://wiki.awesomium.com/licensing/licensing-overview.html – Katana314 Aug 12 '13 at 18:33
  • Apparently, no source access for free licensees... I hate not being able to debug the application I'm working on. – Eugene Aug 12 '13 at 18:38
0

Now I am curious if something like that can be done on top of web browser?

No you don't. If you start with a browser, you'll have to strip down everything on the browser. If you plan to create a desktop application from web technology, IMO it's more reasonable to start from the rendering engine, which is Webkit or Gecko and their JS engine and build up what you needed from there.

Some IDEs embed a HTML rendering engine for either their web development toolkit or their help viewer. ChromeOS and FirefoxOS are build on the idea that all their native applications are written in HTML/CSS/JS; Windows's Metro apps, Mac's Dashboard Widget, and the old Yahoo Widget are self-contained application written using HTML/CSS/JS. Then there is also Adobe AIR (that's mostly flash though).

Mozilla played around with Prism (no, not that PRISM), which is meant to be a platform for writing desktop application using web technologies, although this project is no longer active. I believe that - instead of bringing web technology to desktop application - they want to bring desktop capabilities to the web instead (i.e. pushing for Canvas, WebGL, Geolocation API, Web Worker, Web Socket, File API, Indexed Database API, ASM.js, etc). Although it's notable that Firefox OS is going to that other direction.

Lie Ryan
  • 12,291
  • 1
  • 30
  • 41
  • I am familiar with embedding HTML viewer - and I am not interested in this approach. Instead I would like to have my whole UI to be HTML - only chrome will stay "native". But I need to do a lot of "native" stuff to support the functionality. – Eugene Aug 12 '13 at 18:33
  • @Eugene: they're technically the same thing, whatever framework you use will need to embed a HTML viewer widget. The only difference is that you're keeping native code minimal (just enough to bootstrap the HTML widget). – Lie Ryan Aug 12 '13 at 18:41