web-browser based GUI

Question

I am working on an application in Linux which will interfaces with hardware. One of the requirements is to create the GUI in Web-browser . the application will be c++ based. I m not familiar with web realted stuff so i want to know Is it possible to do such a thing (currently it's a console application take input from txt file/cmd line). gui will be simple using button and showing output messages on browser from the application. i want to know which technologies/languages are involved and how can it be done. some of the idea i read but havn't found anything concrete yet. if u have any idea about these or a better suggestion please share

• run the app in background and communicate with browser ?
• call library functions directly from browser ?

any other idea ?

Answer 1

usually in web based applications the communication is "pull" from the client-side (the web gui), you cant relly "push" data from the application to the web gui, its more like the gui polling the web server*

• : there's comet, which uses very long lived http communications to simulate "push" - essentially the client submits an http request which just hangs there until the server wants to "push" something, in which case it returns a response.

basically youre looking for an embeddable http server. such a component runs as part of your application (in a seperate thread) and can call your internal functions in response to http requests, and return a formatted response. ideally I'd suggest using something like JSON-serialized request/responses, which would mean your web-interface only communicates commands and data, and the gui can be thought of as a stand-alone application (that happens to be written in HTML/javascript) that fires JSON-serialized commands to the server and gets back JSON-formatted responses. you could also substitute JSON for XML.

the web interface can then be served as static HTML content, either from the same embeddable web server or from another

Answer 2

These are how I thought of doing this, in order of complexity for me:

1. Create a simple server-side-language (PHP/Python) website that can communicate with (ie launch and process the return of) your application

2. Modify your application to have a built-in webserver that just punched out HTML (command line parameters taken through the URL)

3. Modify the app to publish JSON and use javascript on a simple HTML page to pull it in.

You could write a Java applet (as you've tagged this thread) but I think you'd be wasting time. This can be quite simple if you're willing to spend 10 minutes looking up a few simple commands.

Answer 3

I would start by setting up a regular HTTP server, like lighttp or Apache httpd.

You say you already have a command line program that does the actual work - As a first step, I would reuse that, and configure the web server to call your program using CGI - see forexample http://httpd.apache.org/docs/2.2/howto/cgi.html for apache

Finally, I'd pick some javascript framework like jQuery or YUI with Ajax capabilities to do requests to the server to call the CGI script from within a webpage. You could also create a form-based web application without ajax or any framework, but that would require you to stuff all kinds of logic in your program to generate HTML pages. By using Ajax, you can leave the command line application as is, and parse any responses it gives with javascript, and then use that to dynamically change the webpage in a way that would make sense to the user.

If this all works, then I would try to figure out how to package all these components. Perhaps you just want to create a simple archive with all the programs inside, or maybe you want to go as far as actually embedding the webserver in your program. Alternatively, you may want to do it the other way around and rewrite your program as an ISAPI module that you can plug into your webserver. Or if that's not integrated enough still you could write your own (partial) HTTP server. That's really up to you (I'd probably spend time and energy on searching for the leanest, meanest existing open source http serverr and use that instead)

At any rate, the prior steps won't be lost work. Most likely, developing the web page is going form a substantial part of the work, so I would probably create a quick and dirty working solution first using the age-old CGI trick, and then develop the webpage to my satisfaction. At that point you can already have an acceptable distributable solution by simply putting all programs in a single archive (of course you would have to tweak the webserver's configuration too, like changing the default port so it won't interfere with existing webservers.) Only after that I would spend time on creating a more integrated fancy solution.