\begindata{text,538765120} \textdsversion{12} \template{default} \formatnote{.ds CT .ds CB - VI-\\\\n(PN -}\majorheading{\bold{ VEE is Object-Oriented -- NOT! }}\center{Dean Rubine, Information Technology Center Gary Keim, Andrew Toolkit Consortium Carnegie Mellon School of Computer Science Pittsburgh, PA 15213 Dean.Rubine@andrew.cmu.edu Gary.Keim@andrew.cmu.edu } \section{Abstract} VEE is a system for producing applications, in particular, applications with highly interactive direct manipulation interfaces. This includes applications with a substantial multimedia component. VEE has two primary goals: ease of use, enabling both non-programmers and programmers to create applications, and extreme portability, allowing VEE applications to run on a wide variety of platforms. In VEE, an object's sole interface is a set of attributes rather than a set of methods, implying that VEE is not object-oriented, at least in the strict sense of the term. VEE gains simplicity and elegance by abandoning the object-oriented paradigm, thus making it possible to achieve its goal of ease of use. \section{Introduction} Application development is too hard. It is well known that producing application software is difficult and costly, often consuming many man-years of expensive programmer time. While a major goal of object-oriented programming techniques is to enable the reuse of past development effort, thus saving time and money, in practice this savings has not been realized to any great extent. The trend toward software that is user friendly has further increased development costs, as modeless graphical direct-manipulation interfaces are much harder to build than the simple command-line interfaces of old. Furthermore, the porting of applications, required if producers are to keep old users and reach new ones, also consumes substantial resources. VEE is an attempt to reduce these costs. This paper describes VEE, a framework for producing applications. After some brief motivation, VEE's design is elaborated. Several examples are presented to give concreteness to the discussion. Implementation is then briefly discussed, after which the paper concludes. It should be noted that VEE is still very much in the design stage. While implementation has begun, the results are still very preliminary and many of the claims made in what follows are quite speculative. Furthermore, this paper is very much work in progress, and will likely change significantly in the future. We are interested in any comments you might have. \section{Motivation}\bold{ } We have already mentioned that reducing the cost of application development and porting are our prime motivations. We further wish to allow disparate applications to be easily integrated, and to allow non-programming end users to create their own custom applications. We believe this is possible only by dramatically simplifying the concepts needed to produce applications, as well as the sheer effort involved. We use the term ``applications'' in its usual sense. We are particularly interested in information browsing applications (e.g., stock reports, mail reading, database access), personal data organization (e.g. a Rolodex application like one might build from Hypercard) and multimedia presentations (e.g. interactive courseware). Furthermore, applications needed to produce multimedia presentations (e.g. audio signal editing, music sequencing, video storyboarding and editing) may all be built in VEE. As will be seen, by building such applications in VEE we aim to allow them to be easily integrated, thus blurring the currently sharp line between separate applications. Ideally, the end result of VEE is an information habitat which appears to the user as interconnected views on many different types of interrelated data rather than as discrete applications. In examining the current methods of application development, we see a number of areas that can be improved. In particular, existing applications built using interface toolkits generally require substantial coding for (1) creation, grouping, and layout of user interface components, (2) communication between user interface objects and the application core, (3) behavior of user interface components, apart from the core application, (4) providing persistence of application and interface data, and (5) enabling end-user customization. Conventional interface builders assist with the creation and layout of interface components, but offer little assistance elsewhere. VEE is an attempt to eliminate programming for all five of the above tasks. \section{VEE's Design} \subsection{Influences} VEE's design is influenced by work done in a number of areas of computer science: \indent{- Object-Oriented User Interface Toolkits and Interface Builders - Programming By Example (e.g. Eager, Metamouse) - Constraint-based UI Tools (e.g. Garnet, ThingLab) - Visual Programming Languages (e.g. MAX, Fabrik) - Application Builders (e.g. 4GL languages, HyperCard) - Spreadsheets - Network Databases - AI frame representation languages (e.g. Minsky, FRL, KRL) } \subsection{VEE's Object Model: a Set of Named, Typed Attributes} Like most object-oriented systems, the VEE universe consists of a sea of objects. However, VEE objects do not export methods. Instead, a VEE object exports a set of named, typed attributes. The basic attribute types supported are quite limited: the value of an attribute may be a boolean, integer, floating point number, string, nil, atom, list, reference to a VEE object, pointer to a C function, or pointer to a C structure. All but the latter two types may be automatically read from or written to a file, making possible the saving and restoring of VEE objects without explicit programming. \subsection{Operations On Attributes: Set and Get} By exporting only attributes, VEE greatly simplifies the interface to objects. There are only three operations possible on an attribute: \bold{set}, \bold{get}, and \bold{equate}. Set is used to assign an attribute a value. Get is used to query the value of an attribute. Equating two attributes constrains them to be equal, and is the sole method of interobject communication in VEE. For example, consider a slider object: \begindata{raster,538737544} 2 0 65536 65536 0 0 56 195 bits 538737544 56 195 j07h | j13h | j33h | j33h | j33h | j33h | h01f833h | h01f033h | h018033h | h01g33h | j33h | j33h | j33h | j33h | h3fGf3h | h7fGf3h | j03h | j03h | j03h | j03h | hHf3h | hHe3h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g43h | hc0gc3h | hc0gc3h | hc0gc3h | hc0gc3h | hc0gc3h | hc0gc3h | hc0gc3h | hc0gc3h | hc0gc3h | hc0gc3h | hc0gc3h | hc0gc3h | hc0gc3h | hc0gc3h | hcfGc3h | hdfGc3h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | hc0g03h | h80g03h | j03h | j03h | j03h | j03h | j03h | j13h | j33h | j33h | j33h | j33h | h01f833h | h01f033h | h018033h | h01g33h | j33h | j33h | j33h | j33h | h3fGf3h | h7fGf7h | j03h | \enddata{raster, 538737544} \view{rasterview,538737544,47,0,0} \ \begindata{text,539026080} \textdsversion{12} \template{default} \typewriter{ name Slider1 isa aSlider maxvalue 100 minvalue 0 value 64} \enddata{text,539026080} \view{textview,539026080,48,249,216} This slider, named \typewriter{Slider1}, was created by selecting ``New Slider'' from a menu. The slider has a range from 0 to 100, and currently a value of 64. Dragging the slider's elevator with the mouse causes the slider's \typewriter{value} attribute to change accordingly (i.e. the slider sets the attribute). Conversely, setting the slider's \typewriter{value} attribute causes the elevator to move accordingly. It is possible to change the range of a slider simply by setting its \typewriter{minvalue} and \typewriter{maxvalue} attributes. Notice that an object's attribute may either be set by the object itself or externally (from outside the object). Dragging the slider's elevator causes the slider to set its own \typewriter{value} attribute. The slider might also set its own \typewriter{value} attribute in response to one of its other attributes being set, e.g. \typewriter{minvalue} (if it was set to a value higher than the current \typewriter{value}). These are both examples of an object setting its own attribute. Conversely, \typewriter{value} can be set from outside of the object, in which case the slider responds by redrawing (and possibly by setting another of its attributes). \subsection{A Rudimentary Interface Builder } How does the user who is building an application get and set the attributes of an object? The simplest way is to select the object (e.g. by clicking on it) and then choose ``Examine Attributes'' from a menu. By default, a form-based interface which displays the object's attributes (as above) is presented. The user may then type into the attribute fields to change an attribute's value. The slider has many other attributes that are not shown above. For example, there are attributes giving the location and dimensions of the slider. These too may be manipulated using the forms-based interface, or by using the mouse to change the slider's shape and size directly. \subsection{The Prototype-Instance Model} Rather than the class-instance distinction commonly used in object-oriented toolkits, VEE uses a prototype-instance model of objects. In the prototype-instance model, an instance of an object (e.g. \typewriter{Slider1} above) may serve as the prototype (i.e. class) of another object. In other words, the user may make instances of \typewriter{Slider1}. Each instance would initially inherit the value of all of \typewriter{Slider1}'s attributes, including its size and range. Any attributes set in a new instance would become local to that instance and no longer be inherited from the prototype. In essence, the prototype-instance model enables application builders to create new classes without programming. At the simplest level, creating an instance of an object is done by getting the value of the objects \typewriter{new} attribute. If we want the new instance to be a member of a particular group (see below) we set the group's \typewriter{newPrototype} attribute to the prototype of the desired object. Like all other operations in VEE, instantiation is expressed by getting or setting an attribute. \subsection{Equating Attributes} The getting and setting of attributes is the only method of manipulating individual VEE objects. The equating of attributes is the primary way VEE objects communicate with one another. (Objects may also get and set attributes of other objects to which they hold references.) The concept of equating is simply illustrated with an example. Let us create another slider, \typewriter{Slider2}, and equate \typewriter{Slider2}'s \typewriter{value }attribute with\typewriter{ Slider1}'s \typewriter{height} attribute. Dragging \typewriter{Slider2}'s elevator would cause the height of \typewriter{Slider1} to change. Changing \typewriter{Slider1}'s \typewriter{height} (e.g. by some resizing operation with the mouse) causes \typewriter{Slider2}'s elevator to move so as to appropriately indicate the new height. The (human) application builder uses the VEE interface builder (a program) in one of two ways in order to equate two attributes. The first way involves using the mouse to draw a connection between an attribute of one object to an attribute of another (or the same) object. Alternately, an object's attribute may be selected and a menu used to choose any of a number of possible views of the attribute. For example, the \typewriter{height} attribute of a slider, as its type is integer, has a number of possible views, including an integer text field, a meter, a slider, a group of radio buttons presenting a choices of integers, a menu item to set the attribute to a particular value, and so on. Choosing one of these automatically instantiates the selected object with the proper connection already made. \subsection{Grouping } Like many object-oriented UI toolkits, VEE uses hierarchical grouping to indicate view/subview relationships. Subviews are often views that are clipped to be within the parent's view, as this ATK example shows. \begindata{raster,538737800} 2 0 65536 65536 0 0 475 246 bits 538737800 475 246 zzz | zzz | zzz | zzz | 0fZZXc0 | 0fZZXc0 | 0czzxc0 | 0czzxc0 | 0czzxc0 | 0c7ffck06k30g 18h03e7f00f1f zsGf8c0 | 0c4004k06k30g 18h03g301983zs !88c0 | 0c4004k06k30j 03g603183zs!88 c0 | 0c438401f1f3f1 e3e67c01f7319f 3f30d9f1f003g c03003zs!88c0 | 0c47c403"1b!36 c60199"b1b0db 1b1803gc03f03 zsf888c0 | 0c4fe4!03!1b86 36c60199b1b031 999b0318030180 3183zs8088c0 | 0c4fe4!031b19 e636fe0199b1b0 31999b03f80301 803183zs8088c0 | 0c4fe403!1b18 7636c00199"b1 89!1bg!03g3183 zs8088c0 | 0c47c403"1b!36 c60199"b18f!1b 18"033183zsG88 c0 | 0c438401f1f319 e3e67c0199!9f 318619f1f0"03 1f03zs8008c0 | 0c4004v03i03zs 8008c0 | 0c4004v03i03zs 8008c0 | 0c7ffcv03e0h1f zsGf8c0 | 0czzxc0 | 0czzxc0 | 0czzxc0 | 0fZZXc0 | 0fZZXc0 | 0czzxc0 | 0czzxc0 | 0czzxc0 | 0czzxc0 | 0czzxc0 | 0czzxc0 | 0cj60gf0h60g01 c0h06h20h1801 c0h06h421008h 06g70h0180g11 c40220rc0 | 0cj20g4880g20 g0220h02h20h08 0220h02h86!08 h02g88i80g!22 0220rc0 | 0cj20g48h20g02 i02h20h0802i02 h8a!08h02g80i 80g!220360rc0 | 0c1c72c71c21c0 49873c21c88207 2c71c21c702071 c70802072c71c2 1c710204081c71 c2g81cb1c7087 1c402102a72c70 pc0 | 0c228b28a22220 4888a220288208 b28a!2288208a 20880208b28a!22 89020408228822 g822ca2!88a240 4102a8b288pc0 | 0c208a262223e0 48862221e88208 a262223e60208a 07880208a26222 3e610204082281 e2g822898888f 9840810228a0f8 pc0 | 0c208a21!22g48 81!22298208a2 12222010208a08 880208a2122220 1082!08228222 g822884!880421 !0228a080pc0 | 0c228a28a22220 4888bc22268228 a28a!2288208a 28880228a28a!22 8882!08228a22 g8a28a2!88a222 !0228a0888208 nc0 | 0c1c72271c71c0 f1c72071e081c7 2271c71c703e71 c79c01c72271c7 1c704f900f9c71 e7g71c89c71c7 1c13e402272071 c71cnc0 | 0cn20g0880zv82 08nc0 | 0cn20g07zzmc0 | 0czzxc0 | 0czzxc0 | 0czzxc0 | 0czzxc0 | 0fZZXc0 | 0ey08s01zjc0 | 0ey08s01zjc0 | 0el01c0je0l08 l7fc0k01iGe0j 0ekc0h60kc0 | 0el01c0je0l08 k07843ck01iGe0 j0ei07e0cf83e0 67c1f0ic0 | 0el01c0je0l08 k187fc3k01i0e k0ei0ff0dfc7f0 6fe3f8ic0 | 0el01c0je0l08 k67843cc0j01i 0ek0ei0e31f8ee 70fcf71cic0 | 0el01c00780f8 1ee0l08j01d804 0370j01i!0e38 3c0fc1ee1f0e38 1c01b8ee30d877 1cic0 | 0el01c01fe1fc 3fe0l08j026004 gc8j01i!0e38fe 1fe3fe3f8e381d c180e070d8701c ic0 | 0el01c01ce18e 39e0l08j04a004 ga4j01i!0e38e7 38e39e31ce381f e181c1e0d87038 ic0 | 0el01c038701e 70e0l08j091004 0112j01i!0e39 c338070e03c770 1e7387c1f1dcf0 f8ic0 | 0el01c03870fe 70e0l08j161004 010dj01i!0e39 G3fc70e1fc770 1c330f80798ff1 f0ic0 | 0el01c03871ee 70e0l08j2808g !0280i01i!0e39 G0fe70e3dc770 1c331eg398773 c0ic0 | 0el01c038738e 70e0l08j4808g !0240i01i!0e39 c0ge70e71c3e0 1c371c0e3b8073 80ic0 | 0el01c01ce39e 39e0l08j9004g 040120i01i!0e 78e738e39e73c3 e01e76380e7b18 e7jc0 | 0ey08ja0ja0i01 zjc0 | 0ey08i01c0j70 i01zjc0 | 0fYf8i0160jd0 i01ZJc0 | 0ey08i0298i03 28i01r3fK80kc0 | 0ey08i0286i0c 28i01r3fK80kc0 | 0es1c01c0i08i 0501i1014i01r 3ffeh0fG80kc0 | 0es140140i08i 05k14i01m0fHfe g3ffdHf7G80g01 b4hc0 | 0es240140i08i 05k14i01m08h02 g3ffbHfbG80g05 b6hc0 | 0es24022040h08 i05k14i01m08h fag3ff7G1ffdG 80g0db680gc0 | 0es42022440h08 i0ak0ai01m08h 8ag3ff7G1ffdG 80g0db6c0gc0 | 0es42022440h08 i0ak0ai01m08h 8ag3ff7G1ffdG 80g2db6c0gc0 | 0es42022c40h08 i0ak0ai01m08h 8ag3ffbG1ffbG 80g2db6e0gc0 | 0es42042c40h08 i0ak0ai01m08h 8ag3ffbG1ffbG 80g6db6e0gc0 | 0es42042ca0g10 08i0ff8g07fc03 fei01m08hfag3f fdG1ff7G80g6d 36f0gc0 | 0eq04g42041aa0 g1008i0ah0378 g0ai01m08h02g 3ffeG1fefG80g 6936d0gc0 | 0el10j04g4204 12a0g1008i0ai c0g0ai01m08h02 g3ffeG1fefG80 g6936d0gc0 | 0el10j04g4108 12a0g1008i0ai 30g0ai01m080f fc02g3fG7f1fdf G80g6936d0gc0 | 0ej01g10g40h04 g814802a0g2808 i0ai1cg0ai01m 08h02g3fGbf1f bfG80g4936d0g c0 | 0ej01g10g40g40 041081a802a0g 2808i05i07g14 i01m080fG02g3f G"bfG80g493690 gc0 | 0ej01g100440g 404a10812802a0 g2808i05i0180 14i01m08h02g3f GdfG7fG80g4936 90gc0 | 0ej!01300c41g 404a10801002a0 g2808i05k14i01 m080ff802g3fG efbeH80g093680 gc0 | 0e04i03012814 41g404a288010 0290g2808i0501 i1014i01m08h02 g3fGef1eH80g09 3480gc0 | 0e04i02812814 a1gc06a2880g02 90g2808i0286i 0c28i01m08h02 g3fGf71dH80g09 2480gc0 | 0e04i42812814 a3ga0aa2880g01 10g2808i0298i 0328i01m08h02 g3fGfbbbH80g09 2480gc0 | 0e06i4282a812 a280a0aa2880g 0110g2408i0160 jd0i01m08h02g 3fG!fbH80g0124 hc0 | 0e0ai4282a822 a280a0aa2880g 0110g4408i01c0 j70i01m0fHfeg 3fGfdf7H80g01 24hc0 | 0e0ai6282a822 a280a0aa4480g 0110g4408ja0j a0i01r3fGfeef H80h20hc0 | 0e0aia282a822 a280a0b14480g 0108g4408j9004 g040120i01r3f H1fH80kc0 | 0e09h10a482a8 22a28120914480 h08g4408j4808 g!0240i01r3fK 80kc0 | 0e09h2ca482a8 22a48121118480 h08g4408j2808 g!0280i01r3fK 80kc0 | 0e09h24a482c8 22a441211183i 04g4208j161004 010dj01r3fK80 kc0 | 0e10804042a442 4842a441210103 i04g8208j0910 040112j01r3fK 80kc0 | 0e1080608294!44 41144211g03i02 408208j04a004 ga4j01r3fK80k c0 | 0e5040a08298!44 41184212g03i02 a08208j026004 gc8j01r3fK80k c0 | 0e3040910318!44 41182212g01i01 908208j01d804 0370j01r3fK80 kc0 | 0eg310901104c 048118241cg01 i01088208k6784 3cc0j01r3fK80 kc0 | 0eg0b0a01g3007 01101c10g01j09 0108k187fc3k01 r3fK80kc0 | 0eg040601h04g 10n050108k0784 3ck01r3fK80kc0 | 0eh04t030108l 7fc0k01r3fK80 kc0 | 0ey08s01r3fK80 kc0 | 0ey08s01r3fK80 kc0 | 0ey08s01zjc0 | 0fZZXc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0egfeh!03pc00f 807c1c01f0fcg 61c1c018zoc0 | 0egc0g60!03o01 8018c0c6360318 c0g61c1c00czo c0 | 0egc0g6003p01 8018c0c6630318 c0gf1e3c00czo c0 | 0egc07cf9!f37e 3fg7879f8f1f8 g03hcc06633019 f8gf1e3c006zo c0 | 0egfcc663!1b!63 gcccd8d998cg03 g038c0c633031 8cg91b6c006zo c0 | 0egc0c663031b !63g0ce18c198c g03hc01863g61 8c0199b6c006zo c0 | 0egc0fe63031b !63g7c798cf98c g03hc03063gc0 0c01f9b6c006zo c0 | 0eg!c063!1b!63 gcc1d8d998cg03 g18c060630181 8c01999cc006zo c0 | 0egc0c663!1b!63 gcccd8d998cg03 g18ccc0363301 8c030d9cc006zo c0 | 0egc07c39f31b 633fg76798ced f8g01800f8cfe 1c33!f8030d88 c00czoc0 | 0em03j0180g01 80q0czoc0 | 0em63j0180hc0 q18zoc0 | 0em3ej0180zzj c0 | 0ezzxc0 | 0egfeh!03i!c0 h0cgf807c1c01f 0fc006!1c0180 zqc0 | 0egc0g60!03i!c0 h18018c0c6360 318cg06!1cgc0 zqc0 | 0egc0g6003jc0 i18018c0c6630 318cg0f1e3cgc0 zqc0 | 0egc07cf9!f37e 3fgfcdf80g30g 0cc06633019f80 0f1e3cg60zqc0 | 0egfcc663!1b!63 gc6d8c0g30g38 c0c6330318c009 1b6cg60zqc0 | 0egc0c663031b !63gc6d8c0g30 g0c0186300618 c0199b6cg60zq c0 | 0egc0fe63031b !63gc6d8c0g30 g0c0306300cgc0 1f9b6cg60zqc0 | 0eg!c063!1b!63 gc6d8c0g30018c !0630!18c01999 ccg60zqc0 | 0egc0c663!1b!63 gc6d8c0g30018c cc03633018c030 d9ccg60zqc0 | 0egc07c39f31b 633fgfcd8c0g18 gf8cfe1c33f8f 8030d88cgc0zq c0 | 0em03k18rc0zq c0 | 0em63k0cq0180 zqc0 | 0em3ezzpc0 | 0ezzxc0 | 0egfeh!03pc00f 807c1c01f078g 61c1c018zoc0 | 0egc0g60!03o01 8018c0c6360318 ccg61c1c00czo c0 | 0egc0g6003p01 8018c0c6630319 8cgf1e3c00czo c0 | 0egc07cf9!f37e 3fg7879f8f1f8 g03hcc06633019 80gf1e3c006zo c0 | 0egfcc663!1b!63 gcccd8d998cg03 g038c0c633071 f8g91b6c006zo c0 | 0egc0c663031b !63g0ce18c198c g03hc01863g19 8c0199b6c006zo c0 | 0egc0fe63031b !63g7c798cf98c g03hc03063g19 8c01f9b6c006zo c0 | 0eg!c063!1b!63 gcc1d8d998cg03 g18c060630319 8c01999cc006zo c0 | 0egc0c663!1b!63 gcccd8d998cg03 g18ccc0363319 8c030d9cc006zo c0 | 0egc07c39f31b 633fg76798ced f8g01800f8cfe 1c31f0f8030d88 c00czoc0 | 0em03j0180g01 80q0czoc0 | 0em63j0180hc0 q18zoc0 | 0em3ej0180zzj c0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0czzxc0 | 0fZZXc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0egc3j61fcf8l 18g03e1f0e3g07 g6chc0c3e01f01 807e1eg18!7006 xc0 | 0egc3j61818ci 0180g18g063319 b3g0cg6cg0181 c6303183806033 g18!7003xc0 | 0eg66jf1818ci 0180i063319b6 g0cg6cg0187c6 30318f806063g 3c78f003xc0 | 0eg663e637cgf1 81e001fb19f3e7 8019e0063318e6 g1f636cg03gc0 3301818cfc60g 3c78f00180wc0 | 0eg3c!636cg91 !f803!1b198cc0 1b300633180cg 0c636cg03gc063 03018cc67eg24 6db00180wc0 | 0eg18!63600199 803c03!1b1980 c01b8003f1f80c g0c636cg03g!c0 060180c663g66 6db00180wc0 | 0eg18!636001f9 818c03!1b1987 c019e0g301819 c00c636cg03gc1 800c01800663g 7e6db00180wc0 | 0eg18!63600199 818c03!1b198c c018700633181b 600c636cg03gc3 g180180c663g66 67300180wc0 | 0eg18!6360030d 818c03!1b198c c01b3006633033 600c636cg03gc6 0330018cc663g c367300180wc0 | 0eg183e3f6003 0d80f801!f9f0 e76019e003c1e0 31c00c3f6cg01 80c7f33f818c7c 3egc3623003xc0 | 0ep18u0180q03 xc0 | 0ep18vc0q06xc0 | 0ep18zzmc0 | 0ezzxc0 | 0egfcj3fc0h01 80h0f018f87c0 63e1f0g01801f g187c03e1f8gc3 838030zgc0 | 0egc6g30h06i01 80h198198cc60 663318g03g3180 38c6063180gc3 838018zgc0 | 0egc3g30h06i01 80h318318cc60 c63318g03g3180 f8c606318001e3 c78018zgc0 | 0egc33c7cf8c0 0618cf8f1f9e31 803003gc060c6 3018g06g019818 c66033f001e3c7 800czgc0 | 0egc366318cc0 0618d8d9b1b331 803f060181c186 !30g06g07!18c6 60e31801236d80 0czgc0 | 0egc306318cg06 18d8dc31831980 318603g6183f0 60g06g0180187e g331803336d80 0czgc0 | 0egc33e31fcg06 18dfcf319f1bg 318c06g63g30c0 g06g01801806g 301803f36d800c zgc0 | 0egc3663180g06 18d803b1b30bg 318c!0c630631 80g06g318018c6 06331803333980 0czgc0 | 0egc666318cc0 0618d8d9b1b30f g3198180c6606 63h06g319818cc 663318061b3980 0czgc0 | 0egfc3b1cf8c0 060fcf8f1f9d86 g1f181fc7c603 c3f8g03g1f!18 7863e1f0061b11 8018zgc0 | 0er06p03r18zg c0 | 0er36p0180q30 zgc0 | 0er1czzkc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0ezzxc0 | 0fZZXc0 | \enddata{raster, 538737800} \view{rasterview,538737800,49,0,0} Here, there is an outer window which has two subviews: a title bar and a body. The body has the menu bar and the large area as subviews. The large area is further divided into three subviews: one containing graphics and two containing text. The graphics subview is further divided. There are particular group objects in VEE available for a variety of uses: creating vertical or horizontal lists, doing arbitrary layout of subobjects, creating scatter plots, and so on. A window is a group, with the objects in the window being the members. Yet, view/subview relations are just one use VEE makes of grouping. Another use is for persistence: saving a group causes all members of the group to be stored, recursively. Most importantly, groups, as they are objects, may serve as prototypes. Once a group is created, new instances of it may be made. \subsection{Instantiating Groups} Continuing the example, let us select \typewriter{Slider1} and \typewriter{Slider2} and then choose the menu item ``Layout Group'' from the ``New Group'' card. We have now created a new group, \typewriter{LayoutGroup1}, which has \typewriter{Slider1} and \typewriter{Slider2} as members. Like many groups, \typewriter{LayoutGroup1} has attribute for each of its members. In this case, the attributes are named \typewriter{slider1} and \typewriter{slider2}. If we now create a new instance of \typewriter{LayoutGroup1}, we get a new object named \typewriter{LayoutGroup1.1}. \typewriter{LayoutGroup1.1} will have attributes \typewriter{slider1}, which refers to \typewriter{\typewriter{Slider1}.1} (a newly created instance of \typewriter{Slider1}), and \typewriter{slider2}, which refers to \typewriter{\typewriter{Slider2}.1} (a newly created instance of \typewriter{Slider2}.) Most importantly, \typewriter{Slider1.1}'s height is equated to \typewriter{Slider2.1}'s value. In general, instantiating a group causes all members to be instantiated, and any equates between the attributes of members to be replicated isomorphically. However, it may be the case that a group member has an attribute that is equated to an attribute of an object that is not a group member. In this case, the reference to the outside object becomes the value of a new attribute to the group. If this new attribute is ever set (in the group or any of its instances), the equate connections between the object referred to by the new attribute and any group members' attributes are automatically created. In essence, the new attribute has automatically become a parameter of the group. For example, \typewriter{Slider1}'s value may be connected to the \typewriter{volume} attribute of \typewriter{CDPlayer1}, an object that represents the CD player functionality of the local hardware's CDROM drive. As \typewriter{CDPlayer1} is not a member of \typewriter{LayoutGroup1}, an attribute named \typewriter{cdplayer1} (whose value is a reference to \typewriter{CDPlayer1) }is created in \typewriter{LayoutGroup1}. \typewriter{LayoutGroup1.1} will inherit this value, and initially cause \typewriter{Slider1.1}'s \typewriter{value} attribute to be equated to \typewriter{CDPlayer1}'s \typewriter{volume}. If \typewriter{LayoutGroup1.1}'s \typewriter{cdplayer1} attribute is set to \typewriter{MidiSynth3}, the old equate is broken, then \typewriter{MidiSynth3}'s\typewriter{ volume} and \typewriter{Slider1.1}'s \typewriter{value} are equated. \section{Console: An Example } We will now describe how a non-programmer might go about building an application similar to the ATK console application. Console (see the picture above) is a good example of a simple application that can be created with VEE. We begin with a ``New Window'' selected from the menu, which creates an empty window. We then size the window accordingly. Browsing through our library of VEE objects, we find \typewriter{SystemStatistics}, one of whose attributes is \typewriter{loadaverage}. Using the interface builder, we browse the possible views of \typewriter{loadaverage} (a floating point number) and choose \typewriter{ScrollingFunctionDisplay}. We are unaware the scrolling function display is in actuality a group, consisting of an \typewriter{ArrayOfFloat} connected to a \typewriter{FloatFunctionDisplay}. Immediately, a working load average display appears in our new window, and we drag it into position. Similarly, we find the \typewriter{SystemClock} object and create views of the current time, day of the week and data which we drag into place. Examining our \typewriter{ClockView }object we find the boolean attribute \typewriter{isAnalog}. Of the many possible ways of displaying this attribute we choose a \typewriter{MenuItem}, whose attributes we initialize so that the \typewriter{menuTitleString} is ``console'' and the \typewriter{menuItemStringWhenOn} is ``Make Clock Digital'' and \typewriter{menuItemStringWhenOff} is ``Make Clock Analog.'' We set the menu item's \typewriter{isToggle} attribute to true. Immediately we may try out the menu item, and we see that it functions correctly, causing the clock to toggle between analog and digital (and the menu item to toggle appropriately as well). The example can be continued until the entire console application is constructed, but for brevity we stop here. It is clear that for VEE to be successful, a large library of builtin objects must be present, and must have appropriate attributes. These include not only a large variety of user interface widgets (windows, text objects, sliders, buttons, scroll bars, menu items, icons, dialog boxes, file viewers, and so on), but data sources (such as system objects, file systems, databases, etc.) as well. \section{Implementation } As VEE attempts to automatically provide many services that are generally hand-programmed for each application, VEE poses some interesting implementation challenges. Complicating matters is that VEE applications (which are really just VEE group objects) are intended to be portable across platforms. In this section we very briefly consider some implementation issues. At the same time, we discuss the level seen by VEE object creators, who program in C to create new VEE objects. Often, the goal of the object creator is to put a VEE veneer that enables VEE access to existing system facilities such as databases. \subsection{Portability} The level of portability striven for by VEE is different than what can be achieved by simply porting an input layer and graphics model. Whenever possible, VEE objects are intended to be wrappers for existing objects, e.g. widgets from existing toolkits. Thus, the button in the VEE/Motif port is a true Motif button (not a simulation) and the text field in the VEE/Macintosh port uses the Mac Toolbox directly. By using the underlying widgets of other UI tools directly, VEE puts itself in the class of \italic{virtual} toolkits. The advantage of a virtual toolkit is that the look and feel appropriate to a platform is easy to achieve (i.e. a VEE application on a Macintosh behaves like a standard Macintosh application; the same application running on VEE/Windows behaves like a standard Windows application.) In VEE, there is a base set of objects that must be available on every port. A major part of the effort expended porting VEE goes toward implementing the base objects on the new platform. Inheritance is heavily used to achieve portability. The visible, platform independent version of a VEE object (e.g. \typewriter{aSlider}, the prototype of all sliders) inherits from a platform dependent version of the object (e.g. \typewriter{PDSlider}). It is the \typewriter{PDSlider} object that must be reimplemented for each platform. Some objects expected on every VEE port are not base objects, but groups that are composed from base objects. Nonetheless, when a toolkit provides such objects directly (file choosers are one example), the system specific version should be used in preference to the generic VEE version. Using system specific objects when possible increases both efficiency and look-and-feel integrity. \subsection{Methods and Update }At the lowest level, VEE objects are implemented using C functions as methods. Here is an example of a temperature object, which converts Fahrenheit to Celsius via its \typewriter{c} and \typewriter{f} attributes: \typewriter{\smaller{#include "V.h" DECL_OBJECT(aTemperature) DECL_ATTR(f) DECL_ATTR(c) DECL_METHOD(FtoC) DECL_METHOD(CtoF) OBJECT(aTemperature, aSimpleView) ATTR(f) TYPE(float) ATTR(c) TYPE(float) METHOD(FtoC) USES(f) SETS(c) METHOD(CtoF) USES(c) SETS(f) END_OBJECT(aTemperature) FtoC(V self) \{ VSetFloatAttr(c, ((VGetFloatAttr(f) - 32.0) * 5.0) / 9.0); \} CtoF(V self) \{ VSetFloatAttr(f, (VGetFloatAttr(c) * 9.0/5.0) + 32.0); \} }} The C file declares two attributes, \typewriter{f} and \typewriter{c}, and two methods, implemented as the C functions \typewriter{FtoC} and \typewriter{CtoF}. The methods are straightforward implementations of the temperature conversion functions. The declaration indicates that \typewriter{aTemperature} inherits from (is an instance of) \typewriter{aSimpleView}. The method \typewriter{FtoC} is declared to use \typewriter{f} and to set \typewriter{c}. \typewriter{CtoF} is declared similarly.\subsection{ } The internal workings of VEE ensure that when \typewriter{f} is set, \typewriter{FtoC} will be triggered, which will in turn set \typewriter{c} causing \typewriter{CtoF} to be triggered. VEE builds a dependency graph to ensure all such methods are executed in the correct order. VEE ensures that cycles are detected, so the obvious loop is avoided. Furthermore, in this case VEE will ignore the set of \typewriter{f} in \typewriter{CtoF}, as \typewriter{f} had already been set in the current transaction. While seemingly not optimal, this straightforward update strategy has been found to work well in almost all situations and may be explicitly overridden when necessary. In a curious way, VEE inverts the object-oriented programming paradigm. In object-oriented programming, the methods are visible and the data is hidden. In VEE, the data is visible, and the methods hidden. The burden of calling the methods in the right order with the correct parameters is also hidden. The result, we believe, is a drastically simpler and more powerful system. \subsection{Input and Redraw } Some of the most difficult issues is handling input and redraw within VEE. There is a tension between providing extensive support for ports utilizing toolkits with very little policy about such matters, versus not restricting the semantics so much that toolkits with extensive policy may be utilized whole. At the current time, this remains a serious unknown. Like many toolkits, VEE has a platform independent input and graphics layer. Unlike most toolkits, this layer is generally not used by the base widgets. Instead, this layer allows portable VEE objects to be written in C from scratch. Currently, the layer provides for simple line and polygon drawings and multi-font text for output, and canonical click/drag/drop operations for input. \subsection{Garbage Collection } As might be expected, VEE's dynamic object model (arbitrary lists of attribute/value pairs) and VEE's use of lists require that VEE garbage collect periodically. Memory management is thus one more area in which VEE relieves programmers of the burden of tedious programming. \section{Conclusion} VEE's goal is to simplify application construction to the point where programmers spend their time much more fruitfully and non-programmers can actually create significant applications. To do this, the object-oriented paradigm was discarded in favor of a model in which objects export data (and keep methods hidden). The result is much more akin to constraint systems, network databases, and spreadsheets than it is to object-oriented systems. While object-oriented purists may balk, VEE provides the same degree of encapsulation as object-oriented systems, along with a drastically simplified communication method. No callbacks or parameter lists are ever required in VEE. Furthermore, exporting data attributes enables objects to be read to and from disk without programming effort, and thus allows objects to be easily customizable. One exciting aspect of using VEE is that it is always running. There is no edit-compile-test cycle in VEE; at any time the user may manipulate an object and directly watch the effects on the object's attributes. As much as any other feature of VEE, this immediate feedback is likely to lead to increased productivity and user satisfaction. Experimentation replaces compilation. It is genuinely fun to use VEE to rapidly build useful, working, personalized applications. As mentioned above, VEE is still in its very early stages. The low-level object system is running, and ports to two platforms, ATK and Windows, are being developed simultaneously. The grouping operation is only partially implemented, but far enough to verify the soundness of the idea. Implementation of persistence, garbage collection, and the portable I/O layer has only just begun. In the future, we see VEE as a vehicle suitable for building systems for collaborative work. The object data model naturally extends itself to objects living on distributed machine that communicate via message passing. We also wish to apply the idea of trails (timestamped histories of object interactions) for specifying behavior to VEE applications and for multimedia authoring. In all cases, our goal is to relieve the programmer from having to attend to those tasks of application building that may be done without programming. The programmer can then concentrate on providing sophisticated components to be used in such applications. To this end we have created a simple and elegant object model based on objects and operations that anyone can understand and experiment with interactively. It remains to be seen if this model can be turned into a successful system. \section{References} \italic{I don't know how to make a bibliography with ez, and I don't have time to figure it out, so references will have to wait for a later draft of this paper. Sorry. }\enddata{text,538765120}