from a visualization framework to a visual programming environment santiago v lombeyda michael aivazis matt gilbert

isolating the visual framework w by visual framework we define a: w a visual interface (i.e. boxes and lines in Viper) w used to control the setup and/or execution of several interconnected or interdependent actions or modules w where: w semantics and actual execution are controlled outside the visual framework w the visual framework itself is not task specific

growing beyond current paradigms w mostly task specific/focused w most purely developed for visualization w examples: OpenDX, IRIS Explorer, AVS, Viper* w tradeoff between stability and flexibility w do not age well w are mostly extremely dependent on their function and internal data structures w do not allow for new execution paradigms w part large packages w hard to port and share

as a visual ‘elements’ layer in context example display technologies visual framework remote control simulation control executable modules T221/PICA VPE gViz Viper/Pyre VTF

enabling solutions for new needs w more intuitive ways of understanding w how large simulations are put together w how large simulations are performing w debugging w how data are being shared w how to better convey information to [new] users w need more simplicity and more flexibility w needs to be portable w needs to be detached from the executing code w needs to allow for new visual paradigms w needs to be able to share it

generalizing to visual programming environments w more intuitive ways to w link work “modules” together w ways to process data w ways to set up simulations w ways to set up, monitor, and steer complicated, large, long running, remote batch jobs w focusing on not to ‘re-invent the wheel’

module interface visual mockups:

resulting in current work w defining and implementing an API w GL based alone w event callback GTK inspired w object definition OpenInventor inspired w basic visual widget set JavaAWT inspired w flexible visual appearance w defined as variable image composition (skins) w draw as GL images with depth associated w support transparency!

current api structure

vpe api w object oriented w widgets are sample objects rather than base atoms for interaction w callbacks and rendering (gl) can be overriden or extended w event hooks come in from GLUT, GTK, etc w but not GLUT* nor X dependent w basic events needed must be passed to vpeRoot * currently researching text rendering (freetype? pango?)

vtf monitor as a prototype w basic tools for fast prototyping w style options w predetermined w GIMP/Photoshop images and masks w gui creation w blade w an ‘xml’ glade w direct use of api

summary w goal: w isolate visual layer, in order to enable new paradigms and better interaction w offer clear view of system’s state w allow precise and efficient control w offering a true sense of ownership

visualization frameworks santiago v lombeyda michael aivazis CALIFORNIA INSTITUTE OF TECHNOLOGY