Greg, Thanks. I forwarded your very informative message to Mr. Mark Hatch of ICS. I invited him to join opendx-developers list if he wished to follow the thread.
Almost six months ago i was given a complimentary copy of BX Pro 5.0.1 for Linux by Mark Hatch. When I have time I might play with it and opendx. Suhaib > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > [EMAIL PROTECTED] > Sent: Monday, February 14, 2000 3:33 PM > To: opendx2-dev@lists.berlios.de > Subject: Re: [opendx-dev] BX Pro and OpenDX > > > 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 opendx2-dev@lists.berlios.de > > Sent by: [EMAIL PROTECTED] > > > To: "[EMAIL PROTECTED] Ibm. Com" <opendx2-dev@lists.berlios.de> > 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 > > >
