I want to create a local application that has a browser-based UI rather than a stand-alone GUI based on MFC / Qt / etc. If I don't want to run a webserver on the local machine, how can I implement the dynamic parts of my app? Can the browser be pointed to local scripts, executables or libraries on the machine? Can I use a local database directly> What pitfalls are there with this approach?
-
What is the process that has got you to this decision? – u07ch Dec 04 '11 at 23:07
-
HTTP + CSS are great for making a dynamic and portable GUI. But a server is an inconvenience of a local web app probably meaning installation needs elevation, etc. So that's why - want to avoid the server if possible. – paperjam Dec 05 '11 at 09:53
-
2@paperjam: A server does not really need root privileges to install. Running on port 80 needs it but you can run your server on other ports. We've done this to implement a desktop version of our web app. Basically a minimal perl server (our app is in perl) running on a random port and a custom webkit executable connecting to the server. We chose webkit to build our custom browser because it supports the big 3: Windows, Mac and Linux. – slebetman Dec 06 '11 at 03:38
-
@slebetman: Go this far and you may as well dispense with the server and integrate a custom URL scheme / protocol into your Webkit or Chromium browser. Or just intercept http requests before they leave the browser. Server can then be linked into browser executable. That's the route I'm currently considering. – paperjam Dec 06 '11 at 11:42
-
@paperjam: For me I already had the app written in perl so the server route made most sense. Even if not, I'm really hesitant to write web processing code in C/C++ so we'd still have to figure out how to do IPC between Webkit and the script engine. TCP/IP happens to be the most reliable cross-platform way to communicate. Since we're using TCP/IP might as well use HTTP ;-) – slebetman Dec 06 '11 at 17:24
3 Answers
Yes it is, but with limitations. The main limitation is that you can't do any CGI stuff because the browser will open and display your script source code instead of executing them. This has several implications:
- You can't connect to a database. This makes it difficult to do common stuff like storing states and user data.
- You can't set Content-type. This means you can't do any fancy XML stuff like serving SVG files or use XML in XMLHttpRequest.
- You can't generate dynamic images (with ImageMagick or GD). Although with HTML5 you can do it with the canvas.
- You can't read or write to the file system. Again this limits your ability to save data. But it can be done with correct user permissions (more on this below).
But there are workarounds. HTML5 allows you to store data in local storage but obviously this won't work in older browsers. You can store data in cookies instead but that has size limitations. Finally you can actually save to file. You have to instruct your users to modify their browser preferences to allow your script to do this but it can be done. One example of this is TiddlyWiki. It is a self-contained personal wiki in a single HTML file. Every time you save new content the page modifies and saves itself. You may want to look at how they do it for inspiration.

- 20,270
- 7
- 50
- 76

- 109,858
- 19
- 140
- 171
I believe your only options in terms of scripting would be Javascript in this scenario. (Or Java Applets or Flash, but I don't think you want that)
I would suggest taking a look at QT's embedded webkit. You could use that to embed a browser in a simple QT app and use that for most of your UI, then you have the power of C++/QT for your backend. QT is able to link C++ code directly to Javascript.
See the QWebFrame class, especially the addToJavaScriptWindowObject method, and the Qt WebKit Bridge.

- 20,270
- 7
- 50
- 76

- 765
- 5
- 16
If you want the pure HTML route HTML5 will let you create a local database in the browser; with enough javascript coding experience you could write an entire site in it that renders everything in JS rather than loading HTML files. Loads one file and renders everything after that using the javascript engine.
If its a meaningful app and you can write it that way without going mad salute you.
If you are on windows you could cheat and use Active x/ vbscript - but if you are doing that why not write a click once .net application. Without having some web server application component the browser won't be able to talk to a traditional database engine.

- 13,324
- 5
- 42
- 48