Hi All, I'm working on a C++ application and am thinking of building a web-based GUI for it. Basically, the GUI will allow the user to specify input parameters, start the application and pass the parameter settings to the application, and then the application will perform some calculations and send the results/messages to the GUI for plotting/display. I've made GUIs in C# and Matlab before but don't want to do that here because of C#'s platform dependence and Matlab library compatibility issues. I've never made web-based GUIs so I am hoping to get some inputs from you guys: 1. What's the best web-based toolkit/API library? 2. Potential problems? 3. Is it possible to interface the GUI with a C++ application and pass information between the two? 4. Any comments!? [Edited by - faculaganymede on March 16, 2010 3:39:50 PM]

I just stumbled on the wxWidgets website and started to read about it...

Can wxWidgets be the answer??

wxWidgets probably has something there to do web-based stuff, but I haven't used it in ages so I can't say much about it. I haven't used this one either, but QtWebKit will probably get the job done also.

This really depends on how complicated you want to make it. I can think of a number of possibilities but it would help a bit if you provide more details about the application and potential deployment scenarios.

If the application is not running and you want to start it via web frontend, you need to have a webserver running somewhere. For general HTML or for PHP this will typically be Apache httpd.

Another option is to have a small webserver embedded as part of your application. I know of tiny webservers that can be embedded with Java so I imagine there must be one or two for C++ also. This requires that you start the application before you interact with it, but it does relieve you of having to install and configure a separate webserver. Interfacing with the embedded webserver will then be through the webserver's API. If you decide to go this route, then you need to shop around for an open-source embeddable web server that can also handle form submission (HTTP POST). Failing that, it should at least be able to parse the request URL to get the request parameters. Either way would work with providing user input into the application. It would also help if the webserver can handle static content like images and text files.

For the website itself, I recommend you stick with simple HTML for starters. You don't need the power of PHP or other scripting languages for this scenario. Anything complicated is already handled by your application code, so you just need to have the application write out the appropriate HTML. If you are worried about how it will look, the look of a web application is decided entirely on the client side using CSS and &#106avascript. Just have the webserver handle requests for those CSS and JS files.<br><br>If you are going to run a separate webserver, then you will need scripting to interact with your application. You could write a PHP script to execute your application, or you could configure your application to act as a "script" itself using Common Gateway Interface (this will require configuring the webserver appropriately). In this scenario you would also serve the other pages (HTML, CSS, JS, images, PHP, whatever) directly using the webserver.

Thanks for the feedback, aryx & lightbringer.

Quote:Original post by lightbringer
This really depends on how complicated you want to make it. I can think of a number of possibilities but it would help a bit if you provide more details about the application and potential deployment scenarios.

I haven't given much thought into the webserver side of things yet, perhaps that'll be something for the future...

The main reason for a web-based GUI is to stay platform independent. The main purpose of the GUI will be to (1) collect input parameters from the user, (2) start the app, (3) pass user input parameters to the app, (4) display progress bar and any run-time error messages, and (5) make plots of data produced by the app. The ability to access the app over the network would be a good future capability.

The app itself is really just a number cruncher. It should run as a standalone application, gets the input parameters from command-line if there's no GUI. It'll write the computation results to files, from which the GUI plots will be made.

Quote:Original post by faculaganymede
The main reason for a web-based GUI is to stay platform independent.

It may be much simpler to write a second program in Qt (or similar toolkit) and use some inter-process communication to get them to talk. You could also partition off the computation part into a library and then write two separate apps, one Qt and one CLI (and eventually CGI, maybe?). This would keep the number-crunching part independent of frontend technology.

Quote:Original post by faculaganymede
The main purpose of the GUI will be to (1) collect input parameters from the user, (2) start the app,

Getting the app to start using the web has a lot of overhead, as outlined above. You'd have to keep a separate webserver running which may or may not be acceptable to you.

Quote:Original post by faculaganymede
(3) pass user input parameters to the app, (4) display progress bar and any run-time error messages,

Number four will require you to use AJAX (a &#106avascript technique) in the client code. If the app is started using a PHP script, you'd also have to have a method for querying the current state, which would probably be very involved (at least I can't think of a simple solution for that). Using embedded webserver it should be relatively simple if your app is multithreaded (as it will be since you are going to have to accept incoming connections). Using CGI you could do it (maybe) but I don't know the details. Presumably it would work about the same as with embedded webserver.

Thanks for your suggestions, lightbringer!

The web-based GUI is supposed by the simpler part of my task (the main work is on the number crunching application), so I am just trying to find an exiting tool/API that can be used to easily make the GUI.

Basically, I want to be able to access my GUI and application by an URL on a web browser. It doesn't need to work over a webserver yet, e.g. if I type "C:\myApp\myGui.html", I want the GUI to show up on the web browser (and also be able to generate and display the resulting plots). Is that possible?

Thanks for any help, comments and suggestions!

Quote:Original post by faculaganymede
Thanks for your suggestions, lightbringer!

The web-based GUI is supposed by the simpler part of my task (the main work is on the number crunching application), so I am just trying to find an exiting tool/API that can be used to easily make the GUI.

Basically, I want to be able to access my GUI and application by an URL on a web browser. It doesn't need to work over a webserver yet, e.g. if I type "C:\myApp\myGui.html", I want the GUI to show up on the web browser (and also be able to generate and display the resulting plots). Is that possible?

Thanks for any help, comments and suggestions!

A browser can display straight HTML directly from your hard drive, but a "web application" (which is what you are wanting to create) will have to be delivered via a "web application server." Now, you can create a GUI from standard HTML forms, or through a simple web framework, such as J2EE (I recommend Spring framework as a lightweight platform), Ruby on Rails, or with ASP.NET (all of these will require at a minimum an HTTP server). However, more than likely, what you would be happier with is a Rich Internet Application framework, such as Flex or Silverlight.

As far as your underlying application (in C++), one of the best ways to create the sort of separation you see between a browser based GUI and the logical application is through the use of remote method invocation in a SOA design. One of the easiest ways to do this is with a web service. Unless you are married to C++, I suggest using an alternative language and framework for implementing the web service, such as .NET or Java. There are many tools out there to get you up and running a web service very quickly with these technologies (again, Spring can be your friend here).

With all of that said, you will not be able to do what you want in the manner in which you want to do it. I suggest you research a bit about Service Oriented Architecture, Web Services, and Rich Internet Applications.

Quote:Original post by faculaganymede
Basically, I want to be able to access my GUI and application by an URL on a web browser. It doesn't need to work over a webserver yet, e.g. if I type "C:\myApp\myGui.html", I want the GUI to show up on the web browser (and also be able to generate and display the resulting plots). Is that possible?

To make it work over web browser without a server like that will require you (apart from having your app or library locally installed) to write a client-side application that makes use of some browser plugin as a go-between. For example .NET (not very portable), ActiveX (even less portable), signed Java applet (needs JVM installed), Flash (maybe), Silverlight (most likely, but again portability question), or JavaFX (maybe).

1. HTMLayout i would suggest, because its "fast, lightweight and embeddable HTML/CSS renderer and layout manager component" and "No dependencies from installed browsers on client PC" and its free.

2. windows-only

3. yes its designed to be embeddable.

4.

• would be better can be linked in a static library


• cross platform will be even better


• render to memory dc (or render to texture) is buggy