from a

visualization framework to a

visual programming environment

santiago v lombeydamichael aivazis

matt gilbert

isolating the visual framework

by visual framework we define a: a visual interface (i.e. boxes and lines in

Viper) used to control the setup and/or execution of

several interconnected or interdependent actions or modules

where: semantics and actual execution are

controlled outside the visual framework the visual framework itself is not task specific

growing beyond current paradigms

mostly task specific/focused most purely developed for visualization examples: OpenDX, IRIS Explorer, AVS, Viper*

tradeoff between stability and flexibility do not age well are mostly extremely dependent on their

function and internal data structures do not allow for new execution paradigms part large packages hard to port and share

as a visual ‘elements’ layer

in context exampledisplay technologies

visual framework

remote control

simulation control

executable modules

T221/PICA

VPE

gViz

Viper/Pyre

VTF

enabling solutions for new needs

more intuitive ways of understanding how large simulations are put together how large simulations are performing

debugging how data are being shared how to better convey information to [new]

users need more simplicity and more flexibility

needs to be portable needs to be detached from the executing code needs to allow for new visual paradigms needs to be able to share it

generalizing to visual programming environments

more intuitive ways to link work “modules” together ways to process data ways to set up simulations ways to set up, monitor, and steer

complicated, large, long running, remote batch jobs

focusing on not to ‘re-invent the wheel’

moduleinterface

vis

ual m

ock

up

s:

resulting in current work defining and implementing an API

GL based alone event callback GTK inspired object definition OpenInventor inspired basic visual widget set JavaAWT inspired flexible visual appearance

defined as variable image composition (skins)

draw as GL images with depth associated support transparency!

GLUT

GTk

TKL/TK

FreeType

VPE VPEEvent

VPEMouseTracker

VPEObject VPEContainer VPEGUIRootVPEFrame VPEModuleVPEWorkarea

VPELayersVPECollapserVPECanvas VPEStretchCanvas

VPEButton VPECheckboxVPESlider

VPEWire

VPEAction

VPEPipe VPETranslatorVPECommunicator

VPEMap

curr

en

t ap

i st

ruct

ure

vpe api

object oriented widgets are sample objects rather than

base atoms for interaction callbacks and rendering (gl) can be overriden

or extended event hooks come in from GLUT, GTK, etc

but not GLUT* nor X dependent basic events needed must be passed to vpeRoot

* currently researching text rendering (freetype? pango?)

vtf monitor as a prototype basic tools for fast

prototyping style options

predetermined GIMP/Photoshop

images and masks

gui creation blade

an ‘xml’ glade direct use of api

summary

goal: isolate visual layer, in order to

enable new paradigms and better interaction

offer clear view of system’s state allow precise and efficient control offering a true sense of ownership

visualization frameworks

santiago v lombeydamichael aivazis

CALIFORNIA INSTITUTE OF TECHNOLOGY