think-cell technical report TC2003/01 A GUI-based Interaction ...

More documents

Recommendations

Info

5.1 Program Architecture IMPLEMENTATION User Interface CUIObject 0..* 1 CFeature 1 0..* CPPTShape 0..* 1 1..* 1..* PowerPoint Access Layer 1 1 CVisualElement Data Model (persisted) CSmartElement CContainerSE CSmartGrid 1 0..* CPPTDocWnd 1 0..1 0..* 1 1 2 0..* 0..* bound to 0..* 4..* CGridLineDragHandle CUIGridLine 1 1 1 1 CGridLine 2..* 1 CGridLineGroup CPresentation 0..* 1 CPPTFrame CPaintSurface 0..* 1 CPaintSystem Figure 37: Program architecture – relations between selected classes 70 1 1 1 1 2 1
5.1 Program Architecture IMPLEMENTATION The interface to PowerPoint is complemented by the CPPTShape class. There is an instance of this class for each shape – rectangle, arrow, text box and the like – in a PowerPoint document. The methods of this class provide ways to add, modify and displace PowerPoint shapes. While each document window contains precisely one presentation, the same presentation may be opened in multiple document windows simultaneously. Hence, presentations are represented independently from document windows by the class CPresentation. Presentation objects contain static or user specified information about a PowerPoint document. Each presentation consists of a number of slides, which in our data model are represented by instances of CSmartGrid. The smart grid is the link between a presentation and its smart elements. Because a document window can edit one slide at a time, each instance of CPPTDocWnd needs only a single reference to the smart grid that is currently visible. A priori, each slide has a smart grid and a container, which is an instance of CContainerSE. The container spans the entire slide and holds gridlines to represent the positions and spatial relations of its contained smart elements. The container itself is invisible to the user and indifferent against user action. Gridlines, being represented by CGridLine objects, are partitioned by their orientation – vertical and horizontal – and held by one of two CGridLineGroup objects per container. Each group of gridlines always contains at least two gridlines, which indicate the lower and upper bounds of their container in the respective dimension. Smart elements – i. e., instances of CSmartElement – are placed relative to a slide’s container, their location being determined by the gridlines they are bound to. Each smart element represents a self-contained composition of arbitrary complexity that is placed and sized in its entirety. Each smart element is made up of one or more features, which in the case of a chart correspond to columns and labels and are represented by the class CFeature. Features usually have user specified options, but cannot be moved or resized independently from their smart element. A feature, in turn, usually consists of one or more PowerPoint shapes. However, certain features serve only mediating purposes in the user interface and do not have a corresponding PowerPoint shape. In fact, the objects which I call features are essential for the user interface. On request, a feature generates a number of instances of CUIObject – handles or menu items, for example – that provide means for the user to modify the feature (cf. Sect. 5.1.3). All UI objects of all currently visible features are registered with the document window and receive messages therefrom. The visual representation of a UI object involves mapping texture coordinates to screen coordinates and is implemented in the class CVisualElement. This same pattern applies to the user interface representation for gridlines. To be visible and user-modifiable, CGridLine objects generate instances of CUIGridLine and CGridLineHotDragHandle. Indeed, these latter classes are subclasses of CUIObject (cf. Fig. 38(a)) and as such also own visual elements and are message- 71
Page 1 and 2:
think-cell technical report TC2003/
Page 3 and 4:
Contents List of Figures 5 1 Introd
Page 5 and 6:
List of Figures 1 The consultant’
Page 7 and 8:
1 Introduction INTRODUCTION “Layo
Page 9 and 10:
2 Field Study FIELD STUDY Jeff Hawk
Page 11 and 12:
2.1 Qualitative Aspects FIELD STUDY
Page 13 and 14:
Page 15 and 16:
Page 17 and 18:
Page 19 and 20: 2.2 Quantitative Aspects FIELD STUD
Page 25 and 26: 3 State of the Art STATE OF THE ART
Page 27 and 28: 3.1 User Interfaces for Layout Spec
Page 29 and 30: 3.2 Computer Supported Layout STATE
Page 31 and 32: 3.2 Computer Supported Layout STATE
Page 33 and 34: 3.3 State of the Art - Résumé STA
Page 35 and 36: 4.1 A New Approach to Slide Layout
Page 43 and 44: 4.2 Interaction Toolbox INTERACTION
Page 53 and 54: 4.3 Specifying the User Interface I
Page 69: 5 Implementation IMPLEMENTATION The
Page 73 and 74: 5.1 Program Architecture IMPLEMENTA
Page 75 and 76: 5.1 Program Architecture IMPLEMENTA
Page 77 and 78: 5.2 An Application of Dynamic Progr
Page 83 and 84: 6 Evaluation EVALUATION In this cha
Page 85 and 86: 6.2 Case Study EVALUATION presented
Page 87 and 88: 6.2 Case Study EVALUATION AÖGHKÖ
Page 89 and 90: 7.2 Résumé CONCLUSION User Studie
Page 91 and 92: References REFERENCES [Adoa] Adobe
Page 93 and 94: REFERENCES [Hur78] A. Hurlburt. The
show all

think-cell technical report TC2003/01 A GUI-based Interaction ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?