I'd say it was at advanced proof of concept level. It was certainly useable, definitely cool, and I wrote some documentation.
Actually, I thought that was why you didn't support on-line creation of callbacks. But you do allow your users to write and install custom callbacks and widgets, which run in the same address space as BX, and if they crash, they take BX along with, as well. How is that different? Does it make it OK if its just a whole lot more painful to do? And besides, (I write with tongue firmly in cheek) how about those of us whose code never segfaults? Seriously, though, I did this a lot - added a whole lot of infrastructure (C++ code) that my custom callbacks accessed, and if I ever killed BX (I'm not sure I ever did) I certainly wouldn't begrudge BX crashing because I did something stupid. Greg Mark Hatch <[EMAIL PROTECTED]>@opendx.watson.ibm.com on 02/15/2000 10:40:11 AM Please respond to opendx2-dev@lists.berlios.de Sent by: [EMAIL PROTECTED] To: opendx2-dev@lists.berlios.de cc: Subject: Re: FW: FW: [opendx-dev] BX Pro and OpenDX Greg, (and et. al.) The integration you did with BX does interest me and it seems like it would be something that the rest of the OpenDX community might find useful. A couple questions: 1) How cooked was this software? Was it still at the proof of concept stage or was it nearer to being generally useful? 2) In regards to the DX facility that you described that allowed dynamic dynamic linking of callbacks, is this specific to DX or could this be used by non-DX applications? We have yet to expand BX along the lines you did with DX because the user interface being built runs in the same address space as BX. So if the user's program has a bug in it, BX could crash too. Maybe the architecture of DX and how users might use it would make that risk negligible? Regards, Mark At 04:24 PM 2/14/2000 -0500, you wrote: >Greg > >FYI > >Suhaib > > > > > Thanks, I just subscribed! > > > > Greg's description of what they did sounds *very* > > interesting. I forwarded > > it on to Scott (the BX project lead). > > > > I am curious on whether Greg's enhancements worked for > > applications that > > didn't use DX. We do have builtin callbacks (and I think > > that you can add > > them, although I don't think you can add them dynamically > > as he describes). > > I am going to re-read his comments again and maybe drop > > Greg some email. > > > > I want to better understand things here. It sounds very > > promising in which > > case I would be interested in seeing how we can work > > together on this. > > > > Thanks again! > > > > Mark > > > > At 03:50 PM 2/14/2000 -0500, you wrote: > > > > > > >Mark > > >For your info, about OpenDx. If you wish to follow this thread > > >I suggest you go to http://www.research.ibm.com/dx and > > subscribe to > > >Opendx-dev (DX Developers list). It is a low traffic list. > > > > > >I do have BX Pro 5.0.1 copy for Linux which you sent > > several months > > >ago > > >and if you think it's worth while pursuing it, we may consider > > >adding some features for BX Pro. > > > > > >Regards > > > > > >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 > > > > > > > > > > > > > > > > ~ > > Integrated Computer Solutions, Inc. > > Visual Development Tools for Professionals > > > > 617-621-0060 x108 (voice) > > 617-621-9555 (fax) > > > > 201 Broadway > > Cambridge, MA 02139 ~ Integrated Computer Solutions, Inc. Visual Development Tools for Professionals 617-621-0060 x108 (voice) 617-621-9555 (fax) 201 Broadway Cambridge, MA 02139
