BXDX. - a prototype integration of Builder Xcessory and DX. I never got around to showing it to ICS; I certainly should have. In addition to neatly integrating the two, it addressed what I perceived to be the chief shortcoming of BX at that time (maybe still) - the basic approach that you build a UI, test it in "play mode" with some limited built-in Motif callbacks, and then write out C code, which you then hack, using good old vi (or emacs, if you must) to build the bulk of the functionality of the app. Forget running the ap itself under BX; BX isn't an app builder, its a UI builder - and it shows. Using BXDX, you can write and install callbacks while you are building the app, and then use them in play mode - never exitting BX. You can build the functionality of your application concurrently as you build its UI - not as a post-process, after the fact - and to use DX to provide a high-level progamming interface to build that functionality. So BXDX is a fully functioned visualization application builder. You write out the code, compile it and you have a complete app.
I never understood why BX didn't allow you to edit and link in callbacks on the fly. A couple paragraphs on motive. We long believed that the ability to build end-user applications was important for DX's commercial success. While we had originally conceived it as a tinkerer's tool, in which the VPE network editor was a central piece that the end-user would want to use to interactively re-program the visualization on the fly, we came to believe that people might want to build canned applications that they could turn around and deliver to their customers as closed applications. To this end we made several modifications to DX, including the ability to encode networks so that the application provider could protect their intellectual property, the ability to convert DX-ish control panels to a look much closer to standard Motif, and the ability to deliver constrained versions of DX that did not include the VPE (along with a lower-cost license). Even so, the applications you could deliver were constrained by the limitations of DX's GUI builder. DXUI, while extremely easy to use, provides only a limited GUI-builder capability: image windows, the collection of interactors into control panels, and some limited control over the management of those types of windows. Above all, I was always irked by the inability to create a single frame that contained both interactors and image windows. Like a trivial isosurface viewer: a control bar at the top with a File pulldown to load a data file, aybe an Options pulldown to turn axes annotation on and off, a slider at the side to interactively select an isovalue, and an Image window to spin the resulting isosurface around. Couldn't do it then, can't now. So I was looking into alternatives. At which time a prospective customer came and challenged us to a bake-off against AVS. They proposed an application, and paid me (or rather, paid IBM) to come in and build it in front of them, and paid AVS to do the same. Since the app as spec'd had that single-frame appearance, I knew I couldn't build it in straight DX, so I asked them what GUI builder they were accustomed to, and suggested I use it. They were BX users, so I fotched together a little code to interface the two, and went down there. I'll leave it to them to comment on the outcome of the bake-off. So. Back to the trivial example, but lets elaborate it a tiny bit to make it interesting. Suppose we want to feed the area of the isosurface back to the UI to show up in another widget. (I might get the details wrong - its been a couple years - but the following is the basic idea). Any BX user can assemble the widgets necessary; I won't go into that beyond saying that you use the ImageWindow widget BXDX provides, and when you do so, a DX manager panel appears. You press a button and DX starts. You do two things that you normally wouldn't need to do: you give both the destination text widget and the ImageWindow unique names. So. You have to build a network. You push a button in the DX manager panel, and up comes the VPE. You put together a little net, with two NamedInputs to receive the isovalue and the filename, plus what? Import, Isosurface, SuperviseWindow (with the name you assigned to the ImageWindow as a parameter), SuperviseState, Display, Measure. At the bottom you format a string that looks something like "set text widget xxxx to \"The Area Is yyyy\"" (I don't recall the syntax) and passes it to a special module. Save the net. Now you need to add a callback to the UI to pass down the filename. You push a button in the DX manager window, and the callback editor appears. You type in code that pulls the file name from the widget that comes in as a parameter, and calls DXLink to send it to the NamedInput in the net. A button compiles it and a button installs it. Edit the file selector dialog. Find the correct callback resource, and type in the name of the one you just coded. You do the same for a slider widget - create, compile and install a callback that extracts the value from the slider widget and sends it to the named input of the net. Put it in play mode. It all works - even the area message, that is automatically routed to the correct widget by the infrastructure. If people are interested, I might be able to put the pieces together for a show-and-tell. Greg Please respond to [email protected] Sent by: [EMAIL PROTECTED] To: "[EMAIL PROTECTED] Ibm. Com" <[email protected]> cc: Subject: [opendx-dev] BX Pro and OpenDX Greg and Pete Any comments on the following message from Mark Hatch from ICS? Is the BX Pro feature still exists or can this code be activated again? Thanks Suhaib > -----Original Message----- > From: Mark Hatch [mailto:[EMAIL PROTECTED] > Sent: Monday, February 14, 2000 12:35 PM > To: Suhaib Siddiqi > Subject: RE: lesstif on cygwin > > > > > > > > >What kind of BX Pro hooks was it having? Was it an > added advantage > >for data visualization? > > Primarily we were used to build the user interface . A > widget was added to > the BX palette for DX (the closed one ;-) ). Basically, > a developer would > build the ui to his/her application and then drop a DX > widget on the UI. At > that point, DX took over for the actual display. This was > suppose to > compete with the AVS product that combined their 3D > Visualization tool with > our competitor, UIM/X (Visual Edge). > > I suspect that they lost a couple deals to AVS, and this > lack of a GUI > builder integration was mentioned by the customer as > being key to their > decision. Hard to imagine that there was that big an > advantage to having a > visualization object on a GUI builder palette! > > Mark > ~ > Integrated Computer Solutions, Inc. > Visual Development Tools for Professionals > > 617-621-0060 x108 (voice) > 617-621-9555 (fax) > > 201 Broadway > Cambridge, MA 02139
