home *** CD-ROM | disk | FTP | other *** search
/ ARM Club 3 / TheARMClub_PDCD3.iso / hensa / programming / dreamscape / docs / Dreamscape / Docs / Background next >
Encoding:
Text File  |  1996-08-21  |  6.6 KB  |  174 lines
  1.  
  2.                          Some ideas behind Dreamscape
  3.                         ==============================
  4.                           (This page needs updating)
  5.  
  6. Contents
  7. --------
  8.       * RISC OS vs the world
  9.       * Inheritance vs object aggregation
  10.       * The Command class
  11.       * Auto-created objects
  12.       * Shared objects
  13.       * Problems with object aggregation
  14.  
  15.  
  16. RISC OS vs the world
  17. --------------------
  18. The RISC OS GUI is very different to other GUIs. Other GUIs usually have a
  19. few of the following limitations:
  20.  
  21.       * Pull-down menus at the top of the screen or at the top of windows
  22.       * The concept of the 'active window', which is at the front and has the
  23.         input focus
  24.       * An application is a window, and documents are windows within this
  25.         window
  26.       * Modal dialogue boxes - these lock out the rest of the screen
  27.  
  28. But in RISC OS, tasks don't have to put an icon on the icon bar, and the
  29. windows they open don't have to be documents. Menus are not pull down, they
  30. are pop up.
  31.  
  32. Since the RISC OS GUI does not have as many limitations, the hierarchy of
  33. classes is a lot less strict. See the V Reference Manual and the V View of
  34. the World for an example of another class library - V is a Freeware class
  35. library for GUIs such as Windows.
  36.  
  37.  
  38. Inheritance vs object aggregation
  39. ---------------------------------
  40. If you wanted to create a class for viewing a picture in a window, there are
  41. two ways you could do it. The first is using inheritance, where a
  42. PictureView class is-a Window. For example:
  43.  
  44.   class PictureView: public Window {
  45.     Picture *picture;
  46.   public:
  47.     PictureView(Picture *picture);
  48.     ~PictureView();
  49.   };
  50.  
  51. Instead, you could object aggregation, where PictureView has-a Window:
  52.  
  53.   class PictureView {
  54.     Picture *picture;
  55.     Window window;
  56.   public:
  57.     PictureView(Picture *picture);
  58.     ~PictureView();
  59.   };
  60.  
  61. Object aggregation is a lot more versatile, and inheritance tends to be
  62. over-used. With inheritance, you can  have problems inheriting a base class
  63. with virtual functions twice.
  64.  
  65. In the second PictureView example, instead of containing a Window object,
  66. PictureView could contain a  pointer to a Window. This would allow you to
  67. change the window that PictureView uses without having  to delete and
  68. re-create PictureView.
  69.  
  70. In fact, the Toolbox makes use of object aggregation. For example, a SaveAs
  71. object isn't itself a  Window object - you can't manipulate its gadgets
  72. directly. Instead, the SaveAs object contains a Window  object, which can be
  73. read using a SaveAs method.
  74.  
  75.  
  76. The Command class
  77. -----------------
  78. The Command class is used extensively in event handling in Dreamscape. It is
  79. very simple and looks  like this:
  80.  
  81.   class Command {
  82.     virtual void execute() = 0;
  83.   };
  84.  
  85. Other classes can then be derived from this that do specific things. For
  86. example, the class ShowWindowCommand can have a Window object attached to it
  87. and when execute() is called, it shows the window on the screen.
  88.  
  89. You can write a class derived from Command that performs an action, and
  90. attach it to a menu entry. Later you might decide to change the user
  91. interface, so you could just attach it to a toolbar button instead. That's
  92. the advantage of the Command approach - it's very generalised.
  93.  
  94.  
  95. Auto-created objects
  96. --------------------
  97. One thing about the Toolbox is that you can attach objects to other objects
  98. in the resource file, and when the second object is created when the program
  99. is run, the first object is automatically created as well.
  100.  
  101. Dreamscape supports these auto-created objects. For example, toolbars can be
  102. attached to window objects. When the method get_etl_toolbar() for the Window
  103. class is called, it returns a pointer to a Window class. The C++ Window
  104. object is created if it hadn't been previously created - Toolbox object
  105. client handles are used for this. The C++ Window object will later be deleted
  106. when the Toolbox auto-deleted event is received.
  107.  
  108. Gadgets and menu entries are created in a similar way. A C++ Gadget or
  109. MenuEntry object is created when the Window or Menu method get_gadget() or
  110. get_entry() is called respectively.
  111.  
  112. Objects that have their auto-create flag set are auto-created by the Toolbox
  113. when the program is started, although the program won't be able to access
  114. these objects - it's best for the program to explicitly create them itself.
  115.  
  116. Since auto-create objects don't exist in Wimp templates, some of this would
  117. not work in a future Wimp version of Dreamscape. For example, toolbars would
  118. have to be created and attached explicitly - programs that do this would work
  119. under the Toolbox version as well.
  120.  
  121.  
  122. Shared objects
  123. --------------
  124. There is no explicit support for shared objects in Dreamscape. In some cases
  125. shared objects will be useful, in others, they will produce slightly strange
  126. behaivour.
  127.  
  128. For example, if you created two C++ Window objects from one resource file
  129. template that is set as shared, the client handle for the shared object
  130. created will only point to one of the C++ Window objects. So any events
  131. occuring on this window will only be delivered to one C++ window.
  132.  
  133. On the other hand, shared objects are useful when they are used as attached
  134. objects that are created automatically when their parent object is created. A
  135. document window could have a shared menu attached to it, so as long as menu
  136. details are set when the menu is shown (as opposed to as soon as changes are
  137. made), things will work out okay. This is also slightly more efficient than
  138. making a menu a static member of a class, as the menu is only created when
  139. their is one of its parent windows in existance.
  140.  
  141.  
  142. Problems with object aggregation
  143. --------------------------------
  144. There are problems with object aggregation. For example, if a SaveAs class
  145. used object aggregation it would contain a Window object, instead of being
  146. derived from Window:
  147.  
  148.   class SaveAs {
  149.     Window window;
  150.     ...
  151.   };
  152.  
  153. But what happens when you want to attach your Save as window to a menu tree?
  154. The prototype for the function in the MenuEntry class to attach windows to
  155. menu entries could be:
  156.  
  157.   void set_leaf(Window *window);
  158.  
  159. But that only lets you attach Window objects, or objects derived from Window.
  160. We don't want to derive SaveAs from Window, though, because we don't want,
  161. for example, the gadgets in the Window class to be accessible. And anyway,
  162. under the Toolbox a SaveAs object has-a Window, not is-a Window.
  163.  
  164. The solution is for both Window and SaveAs to inherit from a common base
  165. class, BaseWindow, although only Window would provide, for example, gadget
  166. handling. The prototype for the function in MenuEntry becomes:
  167.  
  168.   void set_leaf(BaseWindow *window);
  169.  
  170.  
  171. Mark Seaborn
  172. mailto:mseaborn@argonet.co.uk
  173. http://www.argonet.co.uk/users/mseaborn/
  174.