from Proceedings of ICMCS ’94
Integrating Object-Oriented Scripting Languages with HyTime John F. Buford, Lloyd Rutledge, and John L. Rutledge Interactive Media Group Department of Computer Science University of Massachusetts, Lowell.
Abstract HyTime provides a comprehensive set of primitives for composing hypermedia documents, but does not provide facilities for representing interaction or dynamic behavior, areas which are required in commercial multimedia authoring environments. In previous work we have developed and implemented a prototype HyTime engine called HyOctane in which HyTime interactive multimedia documents can be stored and retrieved. In this paper we extend this work to include scripting language facilities, an area currently not dealt with by the standard but which is crucial in order to represent interactive multimedia documents. We compare different approaches to integrating HyTime document type definitions with scripts and describe the extensions to our engine architecture and implementation status.
1: Introduction HyTime is a well-known international standard for defining models for multimedia and hypermedia documents [1]. Although there are a few other research models for multimedia document architectures [2,3], HyTime has generated attention for its perspective on fundamental hypermedia modeling concepts and status as an international standard, particularly with respect to its relationship with SGML [4]. In previous research [5] we have presented the implementation of HyOctane, the first HyTime engine described in the research literature. In this paper we discuss new results related to the integration of scripting languages with HyTime documents. Although scripting languages are considered to be a significant component in multimedia applications development, they have received little attention in the technical literature. Our research goal is not the design of better scripting languages, but instead to integrate scripting languages with hypermedia document architectures.
Copyright © 1994 IEEE
Scripting languages are special purpose application programming languages. Examples of commercial scripting languages for multimedia applications include OpenScript used in Asymetrix Toolbook, HyperTalk used in Claris’ Hypercard, Gain Technology’s GEL, and Lingo used in MacroMedia Director. These languages are designed to permit authors of multimedia documents to add interactive behavior to the application without having to resort to conventional software development techniques. Though scripting languages are procedural languages, the syntax is typically simplified to make script development more accessible. A significant component of most scripting languages is the run-time environment available to the author, which includes access to databases, graphic user interface services, multimedia devices and players, and student answer evaluation and historical records. HyTime was not designed with consideration of use in a scripting environment. There are no modeling constructs to treat scripts as anything other than opaque content. The basic problem from the HyTime perspective is that the document elements have no a priori correspondence with the objects defined in the scripting language, and there are no architectural forms to identify such correspondences. Since HyTime modeling constructs have no interactive semantics, the interpretation of the relationship of script content and HyTime schedules and links, for example, is left to each application. On the other hand, existing scripting languages have not been designed to work with HyTime. For example, a basic goal of HyTime is the elaboration of the logical document model, and HyTime can be used to develop an unlimited number of different document models. In most scripting environments, the basic document structure is fixed by the application. For example, in Toolbook every document is a “book” with “pages”; in HyperTalk every document is a “stack” with “cards”. Any associations between document elements or application-specific document semantics are
page 1 of 10
from Proceedings of ICMCS ’94 embedded in the scripts and difficult to identify. Despite these problems, we take it as axiomatic that the ability of HyTime processing systems to support existing commercial scripting languages will contribute more to the acceptance of HyTime than development of a HyTimespecific scripting language will. We anticipate that similar to programming languages, no single language will dominate, but a variety of factors will cause current and new languages to co-exist. Consequently this paper is concerned with the integration of HyTime with contemporary multimedia scripting languages, specifically object-oriented ones. The key results of this work are to identify and evaluate: 1) the key integration issues, 2) mechanisms for extending HyTime documents with script objects, 3) ramifications for the engine, the document, and the scripting language, 4) implementation experience. The rest of the paper is organized as follows. The next section briefly reviews how the engine is positioned in the architecture of distributed multimedia systems. Section 3 reviews the characteristics of representative multimedia scripting languages. Section 4 discusses the placement of scripts in documents using HyTime constructs. Section 5 presents an example of a HyTime application that uses script processing. Section 6 discusses some related work.
2: Architectural Context 2.1: HyTime Architectural Overview The HyTime data model, as described in the standard document, provides the representation of the structuring of a hypermedia document in terms of presentationindependent concepts. For example, HyTime does not represent the actual media content of a document. Instead, a document’s media objects are placed in HyTime containers which exist in a hierarchical document structure. HyTime, with SGML, defines this structure. These media objects can also be specified by HyTime as the ends of hyperlinks. Furthermore, these objects can be contained in HyTime events which have a placement in relation to those of other object-containing events within a coordinate system. In HyTime, this placement is referred to as scheduling, even when the placement is not along a timeline. The HyTime standard document does not specify a processing model for conforming documents, but several have been suggested [5, 6]. In an earlier publication we proposed a three layer data processing model [5] (see 1
Copyright © 1994 IEEE
figure 1). In this model the SGML parser parses a document to generate an SGML database layer which represents the document’s logical structure in terms of SGML syntax objects. The HyTime engine then accesses these objects and determines which of them form HyTime constructs. These constructs are then processed into HyTime semantic objects residing on the HyTime database layer. These HyTime objects include hyperlink and event scheduling objects, and some structuring objects representing concepts which are outside of the scope of SGML. There is also an application database layer, whose contents are determined by the application from the contents of the SGML and HyTime layers. In all of these processing models the application is considered that which processes the information the SGML parser and HyTime engine do not process. This information includes media objects as described above, which are not processed by HyTime. The application is also considered that which determines how the SGML and HyTime objects, which are semantically presentationindependent, map to an actual presentation. The application modifies its display of the media objects based on its interpretation of the structuring, linking, and placement information provided by the HyTime and SGML layers.
2.2: Further Architectural Considerations The models described above could be viewed as suggesting that all information which is not specifically embodied by SGML and HyTime constructs is processed by an application that is independent of the HyTime engine. Further specification of the HyTime processing model from this perspective produces an inefficient model because it is possible for data in a HyTime-conforming document to be what we call HyTime-encompassing. HyTime-encompassing data is data with the following two properties: 1. Encoded as non-HyTime and thus requiring further processing by the application portion of the processing model. 2. Containing semantics which are appropriate for HyTime encoding and processing. Such data can exist, for example, in scripts embedded in HyTime documents. Scripts are text in a non-HyTime notation and therefore would be processed by the application. But scripts often contain data whose nature fits within the semantic scope of HyTime. Scripts often contain, for instance, data which specify when and where
page 2 of 10
from Proceedings of ICMCS ’94 certain script objects are presented. Such data fit within the scheduling functionality of HyTime. The issue of embedded scripts in a HyTime environment is discussed further in section 2.4 of this paper. We are modifying our HyTime processing architecture to enable more efficient processing of HyTimeencompassing data. These modifications include adding to our HyTime engine, called HyOctane, facilities that extend beyond the scope of HyTime. Each of these non-HyTime facilities processes some type of non-HyTime encoded data. When possible, a facility extracts from its nonHyTime code as much HyTime-encompassing data as it can identify. These extra functions allow HyTimeencompassing data is returned for processing by the HyTime-specific functions and not sent to the application.
Information not determined to have potential for representation and processing as HyTime objects is passed on to the application. Thus more HyTime-encompassing information is represented in a unified manner in the HyTime database layer. The following section discusses how our architectural modifications address the HyTime-encompassing data issues raised by the presentation of HyTime-conforming documents in distributed multimedia environments.
2.3: Our Architecture For HyTime And Distributed Environments We anticipate that many hypermedia presentations will consist of multiple processes cooperatively controlling the
Figure 1: HyOctane HyTime Engine Design (adapted from [5]) Multimedia Presentation
Service and Peripheral Control
Database
Data Processor
Application Layer
Application Processor
Classes class defined for each document object
Instances Appl. Instance 1 pointer to SGML layer element derived from
get information needed for presentation
non-SGML file input (graphics, sound,etc.)
Application Loader apply semantics to determine fields create instances query all architectural forms
HyTime Layer Classes Instances ArchForm 1 ArchForm clink_ETF pointer to SGML HyDoc_ETF axis_ETF layer element extlist_ETF fcs_ETF derived from evsched_ETF marklist_ETF etc. xxx_ETF 1 event_ETF
pass application (nonHyTIme) attributes
HyOctane HyTime Engine query dependent instances apply semantics to determine fields create instances query elements with “HyTime” attribute query their attributes and content
SGML Layer Classes element attribute
query all elements
Instances element 2 ... element 1 ::content ::content = “xxx” attribute 2a attribute 1a attribute 2b attribute 1b ... ...
SGML Parser instance creation
SGML character stream input
File System SlideShow DTD
Copyright © 1994 IEEE
SlideShow Instance
Media Object Files
page 3 of 10
from Proceedings of ICMCS ’94
We have adapted the architecture described in section 2.2 of this paper to include this efficiency. This adaptation includes adding a non-HyTime facility to HyOctane that determines the orchestration of media objects within the shared presentation space of the multiple application processes. This adaptation also includes giving HyOctane a context within a particular distributed multimedia environment architecture (see figure 2). In this figure we include an orchestration layer similar to Nicolaou’s proposal to support distributed multimedia applications [10]. The additional non-HyTime facility is called the orchestration loader. It translates objects on the SGML and HyTime database layers into objects on the orchestration layer. It also translates orchestration-related HyTimeencompassing code into HyTime objects. Our distributed multimedia environment architecture and the context it provides HyOctane are discussed in the following subsection.
2.4: A Distributed Multimedia Environment Architecture HyOctane exports facilities and services using a distributed object management facility (DOMF) such as the one is the CORBA system [7]. The top layer of the architecture contains the processes that make up the HyTime application. From now on we refer to these processes as separate applications. Each application has a DOMF interface for communicating with HyOctane. HyOctane transmits non-HyTime encompassing information to the applications. For example, one application could receive from HyOctane information it
Copyright © 1994 IEEE
needs to determine a video image, and another application could process its information to produce a sound. Figure 2: HyOctane in Context of Distributed Multimedia Environment Architecture Distributed Multimedia Environment Application 1 DOMF I/F
Application 2 DOMF I/F
Application 3 DOMF I/F
Orchestration
System Services
Media Services
RT MIS Network
Cont. Media File System
Real Time OS HyOctane DOMF I/F
resources and peripherals of a distributed environment to produce that single presentation. This collaboration can only exist if the processes share a common understanding of how to orchestrate presentations in that environment. When the processing model described in the previous sections is applied to this scenario, the HyTime application is considered the collection of these simultaneously running processes. If this architecture is further specified with the assumption that each of these processes will independently assume all of the functions of an application then an inefficient architecture is produced. Such an architecture is inefficient because each process is separately translating HyTime objects into objects of the common orchestration model. An architecture that has one process guiding the specification of this orchestration from its HyTime encoding would be more efficient because the overhead of inter-process cooperation in this orchestration would be eliminated.
HyTime Facilities
HyTime Database Layer
Scheduled Event
Orchestration Facilities Orchestration Database Layer y t
x
Media Object
Scheduled Event Actual Data Communication Implied Data Communication
The applications transmit the objects they produce to the orchestration layer, which then coordinates their presentation. In our previous example, the orchestration layer would ensure that the sound objects are presented in sync with the video objects. The specifications of these orchestrations are received through the DOMF from HyOctane, which determines them from processing the orchestration layer objects. The layer below the orchestration layer of this architecture contains the resources and peripherals the orchestration layer and applications access to create the presentation. A real-time operating system underlies these resources and peripherals. The HyTime encoding of the orchestration of a presentation will be done primarily with HyTime scheduling objects. The most important of these objects is the event, which contains a media object and specifies its scheduling for all the dimensions its placement can vary along. SGML and HyTime alone can often be used to completely define the file system location of a media object. Such a definition uses the entity construct of SGML and the location addressing facilities of HyTime.
page 4 of 10
from Proceedings of ICMCS ’94
2.5: Our Architecture For HyTime With Embedded Scripts The embedding of scripts within HyTime-conforming documents could involve treating scripts as media objects in fashion. A script would be a single object, just as a video clip, audio clip, or still image would be. This paradigm works well from the document representation perspective. This paradigm is, however, inefficient for the reasons explained in section 2.2 of this paper. Scripts frequently specify object scheduling and placement. They can imply hyperlinking by defining branching that is determined by user interaction. This structuring, linking, and scheduling information will often be HyTime-encompassing. If all of the processing of these scripts was performed outside of the HyTime engine then the representation of these HyTime-encompassing data would be contained in applications. The relating of this information to directly HyTime-encoded information of the same nature would have to be indirect. Information of this nature would be stored on both the HyTime and application layers of the database, and in different forms. Using the architecture described in section 2.2 we address this issue by defining script processing facilities for HyOctane. Each of these facilities is an interpreter for a particular scripting language. HyTime objects which are containers for these scripts have their contents sent to the engine’s appropriate interpreter. This interpreter then extracts from the script object HyTime-encompassing information and passes it back to the engine for HyTime representation and processing. Non-HyTime information is also extracted by these facilities and sent to the application in the appropriate manner. The advantage of having the script interpreting be internal to the HyTime engine is that the results of this processing are available to the engine’s facilities, both in and out of HyTime’s scope, in a more efficient manner. For example, if a script contains the specifications of a timeline, HyOctane could translate those timeline objects into HyTime scheduling constructs, and thus the media objects within the script would have their timeline placement handled in the same processing context as the document’s media objects that are contained outside the script.
3: Characteristics of Object-Oriented Scripting Languages Scripting languages such as HyperTalk and OpenScript are object-oriented in that there is inheritance between Copyright © 1994 IEEE
classes and object operations are performed using a message passing syntax. Programming complexity is limited by using a static class structure and a simplified language syntax. The Hypertalk class hierarchy is based on a stack of cards metaphor, which plays an important role in how the user navigates a Hypercard application. • HyperCard • Home stack • Stack • Background • Card • Buttons or fields The OpenScript class hierarchy follows a book metaphor: • Book • Page • Background • Graphics • Buttons The objects in these hierarchies have methods and properties. The hierarchy is also used to define how events and messages are propagated. Because these hierarchies are fixed, a “document” is restricted to a tree of depth at most 6 or 7 levels. Nodes in the tree are instances of the classes of the scripting language, and have properties or attributes as defined by these classes. Language syntax is simplified in order to make the language more accessible. For example, a conditional can be expressed in HyperTalk in one of several ways: HyperTalk: if number of this card is 10 then ... C: if(card.number = 10 ) { } The use of this English-like syntax is intended to increase the readability of the scripts, though at the cost of greater verbosity. Scripting languages derive a significant amount of their power from the run-time environment associated with the language, including access to GUI functions, objectoriented structured graphics, database and file operations, math and string functions, and so forth. As platforms have added support for multimedia device and continuous media control, scripting languages have acquired these functions through library calls. However, other than library calls for multimedia presentation, few scripting languages or multimedia-oriented visual programming languages have the facilities to represent synchronized playback,
page 5 of 10
from Proceedings of ICMCS ’94 conditional temporal composition, or complex hyperlink models. This is where the hypermedia modeling constructs of HyTime can be used advantageously. As an example of the document model implied by these script-based authoring environments, consider Figure 3. The top-level object is the root of the document. Scripts at this level are typically for initialization of the application, including device initialization and database opening. As pages in the book are presented and user interaction occurs, events are generated which cause the corresponding scripts for these objects to be evaluated. Below the page level are other objects such as graphics and buttons. These can have scripts associated with them to handle user input or perform animation, for example. In the next section we discuss different ways of integrating these static object-oriented languages with HyTime documents. We also briefly discuss the issues of integrating with object-oriented languages in which classes can be defined dynamically. Figure 3: Skeleton of document structure and associated scripts for conventional scripting languages
needed. A HyTime document model is defined by a Document Type Definition (DTD). The DTD defines the applicationlevel semantics for document elements based on HyTime primitives. Using HyTime, the DTD designer creates elements types for temporal composition and synchronization, layout, transformations between application spaces, and external media content. Hierarchical relationships between document elements are defined using SGML constructs. Arbitrary associations can be represented using HyTime links. Script objects can be added to any DTD by creating new document elements in the appropriate places in the document. For example, a script element could be defined to contain script language content (an opaque type from the standpoint of HyTime). Other elements in the document which might contain scripts would have to include script elements in their inclusion list. For example, the following definition says that a page element can contain zero or more graphics elements, zero or more button elements, and an optional script object.
Book Scripts for book Page 1 Scripts for page 1
If a document is intended to be portable to several scripting languages such that script objects of each type could be included in the same document instance, then we could extend this definition as follows:
Object 1 Scripts for object 1 ... Object M Scripts for object M ...
( graphics*, ) > o empty> #fixed script #fixed "HyperTalk"
Page N
Here the default script type is HyperTalk.
4: Integrating Scripts with HyTime Document Models 4.1: Document Extensions One of the strengths of HyTime is its comprehensive set of modeling primitives from which multimedia document models can be composed. A scripting language can add interactive behavior to the HyTime model, a critical missing element in the current HyTime definition. If an existing script language is to be used, then some way to associate HyTime document elements with script classes is
Copyright © 1994 IEEE
In addition to including script objects in the document, there is a need to identify a correspondence between script language classes and document elements. That is, we want to know that a DTD element “page” corresponds to the script language class “page” or “card” so that the document content gets the correct interpretation by the script language interpreter. There are several alternatives to consider, in increasing generality: 1.
Define a DTD for each script language: For each scripting language, define a DTD which represents its document model. For example, a DTD for HyperTalk might contain: page 6 of 10
from Proceedings of ICMCS ’94
This is the most flexible, since it provides the possibility of writing DTDs for future scripting languages as well as existing ones. Notice that default values for object instances fields can be defined in attribute lists for the corresponding element definitions.
4.2: Script Language Extensions Fixing the DTD makes it difficult for the application designer to extend the script language document semantics by using HyTime constructs. 2. Define architectural forms for each script language. Similar to how HyTime extends SGML, new architectural forms could be defined which create the necessary associations. Instances of HyTime architectural forms are recognized as SGML elements that have a “HyTime” attribute with a particular value. In the following example we define an imaginary architectural form extension to SGML called HyScript, which contains architectural forms for stack, card, and background objects. As shown, a level2 element corresponds to a stack, a level3 element corresponds to a card, etc.
The examples of the last section would be sufficient for translating non-HyTime script-based documents to HyTime documents in which the DTD served primarily as a container for the document model defined by the scripting language. In this case the use of HyTime is transparent to the scripting language. It references the same objects with the same functions using the same syntax. The difference is that the document content, including the scripts, has been interchanged using a HyTime DTD. From the HyTime perspective this provides integration with existing scripting languages, although in a limited way. The DTD can also contain element definitions that should be treated as an extension to the existing scripting language. For example, as mentioned previously most scripting languages have limited facilities for temporal composition and synchronization of a collection of media streams. Such models can be defined using HyTime primitives and executed by having the HyTime engine interpret them. The script language will need an API in order to access these facilities. This API can be added to the scripting language by a combination of new class definitions and new functions. The approach taken will depend on the scripting language syntax.
Although this approach is less restrictive than the previous, it requires that the class names for the scripting languages be fully enumerated.
For example, a generic API that works with many different composition abstractions includes the following functions, where element is the reference element which identifies a HyTime schedule:
3. Define architectural forms for identifying arbitrary class associations:
set_current_position(element, position) get_current_position(element)
play(element) rewind(element) fastforward(element) play_reverse(element) pause(element)
Copyright © 1994 IEEE
insert(element) delete(element) Similarly, to access HyTime links as a result of user interaction, the following approach could be used. Notice that interpretation of address references used in the link is handled by the engine transparently to the script language interpreter.
page 7 of 10
from Proceedings of ICMCS ’94 on button_down dest = get_destination_element(link_element) class = get_element_type(dest) if class is page then goto dest end The approach described in [5] is to implement generic services such as link management and HyTime schedule interpretation in the engine and provide access to the services by exporting an API to the application layer. These same functions can be used by scripts to obtain use of the HyTime model functionality.
5: Detailed Example In previous work we have described an application of HyTime called SlideShow which we have developed to run on our HyOctane engine [5]. We have since extended HyOctane and SlideShow to process tcl scripts, and we are 4
currently extending the system to process scripts in Hypertalk, OpenScript, and other multimedia scripting languages. Figure 4 diagrams our DTD for the script processing version of SlideShow. (This DTD is available via anonymous ftp at imgftp.uml.edu in the file pub/ hytime/SlideShow_v2.0.dtd.) It features the addition of a script element type definition. In documents conforming to this DTD, script elements are contained in instances of the HyTime architectural form event and as such they place their content in a schedule relative to other events’ contents. A script element is a media object just as images and animations are, but a script element’s ‘HyScript’ attribute is recognized by HyOctane as a script to be processed by the engine’s script interpreter. A sample document instance for this DTD is in Appendix 1. This sample document contains a tcl script that shows a video.
Figure 4: Multimedia document structure corresponding to the HyTime-conforming DTD (adapted from [5]). in DTD only
element name *=zero or more +=one or more + HyTime architectural form archform (if an name instance of a form) attribute HyTime attribute attribute non-HyTime attribute attribute = fixed value (if fixed in DTD) attribute element reference contents of contents of element (or) element (sequence) file accessed as SGML external entity
HyDoc
axis axismeas = “virspace” axisdim = “1024”
fcs
axisdefs = “x-axis y-axis timeaxis”
axis axismeas = “virspace” axisdim = “1024”
* type butnpres transitn slide
axis +
axismeas = “SIsecond” axisdim = “1024”
evsched
* evsched
*
+
clink
clink
extlist
linkend
linkend
*
event
event
event
event
event
event
exspec
exspec
exspec
exspec
exspec
exspec
“##”
dimref elemref extref axisref selcomp flip
HyScript = “script”
script text
Copyright © 1994 IEEE
page 8 of 10
from Proceedings of ICMCS ’94
6: Related Work Standard Multimedia Scripting Language (SMSL), currently under development by the International Standards Organization, defines a means of including scripts in multimedia documents without hampering their portability. SMSL defines a set of multimedia services which can be accessed from scripts contained in a document. These services are considered universal and equally applicable to all multimedia presentation platforms. SMSL also uses HyTime to define a means of encapsulating the document objects these scripts operate on. In this sense SMSL is an extension to HyTime which provides the methods that act on the document objects HyTime encapsulates. SMSL is in its early stages of development and won’t be complete for several years. The Scripted Document System [9] is built on the Etherphone system at Xerox PARC. Scripts are used in this system to control paths through multimedia documents. The scripts allows paths to be determined dynamically to build active documents. From the standpoint of our research, the Scripted Document System would be a potential use of HyTime scripting extensions.
7: Summary Scripts are an important part of multimedia documentation, but HyTime does not specify the inclusion of scripts in its documents. We present our approach to using HyTime to include scripts in documents. Issues raised by this inclusion are introduced. These include a HyTime engine’s context within a distributed multimedia environment and the engine’s reclamation of HyTimeencompassing data. An overview of object-oriented scripting languages is given. Several models for including scripts in HyTime documents are presented. The design of script-interpreting extensions to our HyTime engine facilities are discussed. An sample HyTime application that uses scripts is described.
8: References [1] ISO. ISO/IEC DIS 10744, Hypermedia/Time-based Document Structuring Language (HyTime), April 1992. [2] Herzner, W., and Kummer, M. MMV--Synchronizing Multimedia Documents: An Extension of CDA for Synchronization and Presentation of Multimedia Documents. Comput. & Graphics, vol. 17, no. 3, 1993, pp. 229-241. [3] Hardman, L, Bulterman, D.C.A., and Rossum, G.V., The Amsterdam Hypermedia Model: Extending Hypertext to
Copyright © 1994 IEEE
Support Real Multimedia. Hypermedia, vol. 5, no. 1, 1993, pp. 47-69. [4] Goldfarb, Charles F. The SGML Handbook. Oxford University Press, 1991. [5] Koegel (Buford), J. F., Rutledge, L., Rutledge, J., and Keskin, C. HyOctane: A HyTime Engine for an MMIS. ACM Multimedia 93. Aug. 1993. (Accepted with revision to Multimedia Systems Journal). [6] Newcomb, Steven R. “The ‘HyTime’ Hypermedia / Timebased Document Structuring Language.” Communications of the ACM, December 1991. [7] Object Management Group (1991). The Common Object Request Broker: Architecture and Specification. OMG Doc. 91.12.1 [8] ISO. ISO/IEC JTC1/SC18/WG8, Text of Standard Multimedia Scripting Language (SMSL) -- Functional Requirements; 2nd Working Draft, September 1993. [9] Zellweger, Polle T. Toward a Model for Active Multimedia Documents. Multimedia Interface Design, ACM Press 1992. [10] Nicolaou, Cosmos. An Architecture for Real-Time Multimedia Communication Systems. IEEE Journal on Selected Areas in Communications. Vol. 8, No. 3, April 1990
Appendix 1: Slideshow Sample Instance ]> page 9 of 10
from Proceedings of ICMCS ’94 toplevel .top wm geometry .top 330x250 videowindow .top.video -width 320 pack .top.video -side top button .top.button -text "End Video" command "destroy .top" pack .top.button -side bottom -fill both .top.video play [hyoctane get entity video] 1 1024 1 1024 1 999999 1 1024 1 1024 1 999999 1 1024 1 1024 5 999999 19 1024 265 1024 1 999999 19 1024 324 1024 1 999999 281 1024 1 1024 1 999999 391 1024 221 1024 1 999999 281 1024 1 1024 1 999999 250 1024 244 1024 1 999999 250 1024 244 1024 1 999999
page 10 of 10
