Slashdot Mirror

← Back to Stories (view on slashdot.org)

Web Interfaces for C++ Introspection?

Posted by Cliff on from the tune-ups-while-still-executing dept.

Milo_Mindbender asks: "For a C++ application I'm working on I want to be able to pop up an interface to a class that will display all the 'tunable' parameters of the class and let me inspect/modify them, while the program is running. The catch is that I'm running on a minimal embedded OS with Open GL but no GUI library. Rather than porting a widget set or writing my own, I was thinking about having the application talk to a web browser, and then use the browser to display the GUI, take user input, and finally push the data back to the app. The classes have metadata that describes the public data locations/types so they can be accessed, but not being a web-wizard I'm not sure of the best way of generating the information I need to create the UI. My first thought is to generate HTML and push that to the browser, but it seems like there must be a better way than this, maybe someone has written a library specifically for doing this sort of thing? Any help/suggestions would be appreciated!"

5 of 66 comments (clear)

  1. Remote XUL by dorkygeek · · Score: 2, Informative

    You may be interested in XUL then. Especially, in remote XUL.

    Also, see Remote XUL Application Development with_Mozilla I and Remote XUL Application Development with Mozilla II.

    You may even be able to create the UI XML files automatically from your interfaces, using a script, or introspection.

    You can then send the data back to your host, using RPCs or a REST-like interface.

    --
    Windows is like decaf - it tastes like the real thing, but it won't get you through the day.
  2. Re:This question is odd.... by MarkRose · · Score: 2, Informative

    Unix has threads, too. Recent Linux kernels have particularly fast threading.

    --
    Be relentless!
  3. Re:This question is odd.... by Short+Circuit · · Score: 4, Informative

    Oh and BTW, fork() and the unix process model sucks as a parallellism primitive.

    You're right...you should use pthreads or nptl instead.

    Some advice from someone who makes the same mistake every now and then...When you learn something in class, don't talk about it on Slashdot for at least a month. That'll give you a chance to think before you type.

    In the mean time, dissing UNIX around here is likely to get you modded "Troll."

    --
    tasks(723) drafts(105) languages(484) examples(29106)
  4. Re:This question is odd.... by GileadGreene · · Score: 4, Informative
    BTW, threads of any sort suck as a parallelism primitive. A better choice would be CSP-style process networks, as implemented in occam and C++CSP. Erlang implements a similar (but not identical) concurrency model.

    Why would you want to use a CSP-style concurrency model instead of threads? To quote from the occam compiler homepage:

    CSP has a compositional and denotational semantics, which means that it allows modular and incremental development (refinement) even for concurrent components. In turn, this means that we get no surprises when we run processes in parallel (since their points of interaction have to be explicitly handled by all parties to these interactions). This is simply not the case for standard threads-and-locks concurrency, which have no formal denotational semantics and by which we get surprised all the time.

    In layman's terms, you get concurrency that can be built up from easily understood pieces (instead of a monolithically concurrent system with locks scattered throughout the code), and an underlying theory of concurrency that lets you understand and analyze your design and ensure that it is, for example, free of deadlocks (I've personally created complex networks of 1000+ interacting processes in a dynamically evolving topology, with nary a hitch). And did I mentioned that the context-switching performance of most of these systems is amazingly good?

  5. Slight variation on the 'generate HTML' theme by ArwynH · · Score: 2, Informative

    How about minimal server-side XML + Client side XSLT?

    Requirements:

    1. minimal http server (There is bound to be BSD licensed code for this somewhere on the net)
    2. Code to generate simple (possibly flat?) XML file. You don't need a library for this, you could just pretend it's a text file if the XML is simple enough.
    3. XSLT and CSS stylesheets

    Now all you have to do is serve the XML and stylesheet, attach the stylesheet to the XML file and watch any XSLT-aware browser do the heavy work of transforming that simple XML into beautiful XHTML (or HTML) for you.

    Benefits:

    1. server side code is farely minimal (just a mini-http server and xml generation code) and some of that (mini-http server) can probably be re-used from elsewhere.
    2. Full content/UI seperation. Client doesn't like the UI? just change the XSLT/CSS till he does, no need to re-write code. You could also write small client program that uses the XML data if client doesn't like using a browser, again no need to re-write code.
    3. Less time-consuming than writing a full-scale UI

    Problems:

    1. Requires XSLT-aware browser. Mozilla and Opera support it no probs. IE supports it aswell, but has a few glitches (suprise!).

    Why re-invent the wheel writing C++ UIs and stuff when there is plenty of simpler ways out there.