home *** CD-ROM | disk | FTP | other *** search
/ The Datafile PD-CD 5 / DATAFILE_PDCD5.iso / utilities / s1 / sprview / !SprView / history < prev    next >
Text File  |  1993-08-04  |  9KB  |  211 lines
  1. // --------------------------------------------------------------------------
  2. // !SPRITEVIEW HISTORY
  3.  
  4. !SpriteView is an application I wrote as an introduction to programming in
  5. the Wimp environment using C++: the (very) partial GNU C++ implementation
  6. written by Thomas Aeby (ported down on 27-Apr-93). I've had to write my own
  7. library of functions but I wouldn't wish *them* on anybody!
  8.  
  9. Any additions/alterations that have come about due to other people's
  10. comments/suggestions have those people's names in brackets next to them. For
  11. example, I started this history file on 28-Jul-93 (Joss Smith).
  12.  
  13. // --------------------------------------------------------------------------
  14. // VERSION: 0.08a 28-Jul-93
  15.  
  16. So far, I've written a lot of code. The application is set up to allow only
  17. one window but is written to provide for more.
  18.  
  19. All info in the program information window is filled in once the application
  20. starts.
  21.  
  22. The windows in which the sprite reside are customized when the sprite is
  23. loaded.
  24.  
  25. Memory for sprites is taken from the RMA since I thought the Wimp might need
  26. to be able to find the data for redraw whether the application is paged in or
  27. not. That may not be the case though...
  28.  
  29. I split up the code last night.
  30.  
  31. SpriteView:
  32.   • can load a sprite into a (correctly sized) window.
  33.       The window has no system area (even no border). To make redrawing
  34.       faster, the icon and the window have transparent background colours.
  35.   • allows the user to drag the window around the screen
  36.       This entails dragging the sprite with select
  37.   • allows the user to resize the window
  38.       This entails dragging the sprite with adjust
  39.   • is riddled with error checking
  40.       I have made the decision that good error reporting is vital. I'm quite
  41.       happy with the set up although it makes the code a lot more cumbersome.
  42.       There are even mechanisms for reporting non-fatal errors and (in fact)
  43.       if a Sprite is not loaded, the application can continue without any
  44.       problems.
  45.  
  46. Problems:
  47.   • drag operations
  48.       As yet they are incomplete; more control is needed over the window and
  49.       which part of the sprite is showing. So far, dragging the window means
  50.       it is brought to the front (and there is no back icon) and resizing it
  51.       leaves it where it is on the window stack. This is caused by the use
  52.       of select and adjust.
  53.   • minimum window size
  54.       The window can be made VERY small and this is not really desirable.
  55.       However, I have to allow sprites of any size so I must make the
  56.       minimum size different for different size sprites, with an upper bound
  57.       for the minimum size.
  58.  
  59. // VERSION: 0.09a 28-Jul-93
  60.  
  61. The drag operations now work as desired. That is we now have:
  62.   • move sprite
  63.       linked to Drag
  64.   • resize sprite
  65.       linked to Alt-Drag
  66.   • scroll sprite (horizontal, vertical, and bi-directional)
  67.       linked to Shift-Drag
  68.       Adjust and left,right Shift Keys dictate the behaviour of the scroll
  69.       
  70. I've also implemented
  71.   • put to back
  72.       linked to DoubleClick
  73.  
  74. I've created a !help file which details all of the behaviour I would like in
  75. the finished product so far.
  76.  
  77. // VERSION: 0.10a 29-Jul-93
  78.  
  79. Fixed bugs, now:
  80.   1) windows open on top.
  81.   2) minimum allowed area depends on sprite
  82.   3) sprites with masks have filled backgrounds
  83.  
  84. Have decided on a policy for having multiple frames on the same sprite. I've
  85. implemented the ideas though have not yet had the courage to allow more than
  86. one window in my compiled code.
  87.  
  88. Got a preliminary sprite menu up and running. The menu contains:
  89.   • New View
  90.      Not yet implemented.
  91.  
  92.   • Lock/Unlock
  93.      Allows you to fix the position of the window and disables all drag
  94.      events. It also ignores any OpenWindow block for locked windows
  95.      and substitutes the status of the window when lock was selected
  96.      but I don't think OpenWindow gets generated so the window drifts
  97.      up and down in the stack. I've allowed DoubleClick to remain.
  98.  
  99.   • Remove
  100.      Works for one Sprite and should work for more.
  101.  
  102. // VERSION: 0.11a 30-Jul-93
  103.  
  104. I have now written the scroll drag operations myself rather than relying on
  105. the Wimp so that the drag looks like the sprite is being moved by the pointer
  106. rather than against it. This has a more intuitive feel.
  107.  
  108. Implemented New View and tested !SpriteView with a maximum of 5 sprite
  109. windows allowed. It worked fine! One problem, though, is that the menu
  110. disappears even if you hold adjust down. It shouldn't but I have a feeling
  111. the sequence of operations I perform in NewView induces this.
  112.  
  113. The new window opens at the bottom left of the screen.
  114.  
  115. Have had one unexplainable crash which happened whilst using a different
  116. application. I don't think I can recreate it but have decided it might be
  117. linked to my use of RMA space directly for my sprites.
  118.  
  119. // VERSION: 0.12a 31-Jul-93
  120.  
  121. I have written all the allocation and deallocation code for my SpriteWindows
  122. myself and no longer use RMA blocks or mallocs. I was just going to use
  123. mallocs but found that no memory was released from the wimpslot once it was
  124. claimed even if I knew my code had freed the pointers.
  125.  
  126. The memory management is now written to use a RISC OS2 style Heap structure
  127. with memory being returned automatically when enough free space presents
  128. itself at the end of the heap. Shifting is not yet performed though adjacent
  129. free blocks are merged.
  130.  
  131. I've included diagnostics which are outputted while the application is
  132. running, into a file called 'DIAGNOSTICS' in the SpriteView directory (if I
  133. set up the code to do so of course).
  134.  
  135. // VERSION: 0.13a 31-Jul-93
  136.  
  137. At last I've got my sprite shifting (Shift-Drag = Scroll Window) to work
  138. properly. The initial direction of the drag dictates which way the window can
  139. move. If Adjust is used to start the drag, the window can be shifted in any
  140. direction.
  141.  
  142. I've taken resizing from the wimp now. You can resize any side/corner and the
  143. picture remains still unless the frame size expands so as to make moving
  144. necessary. Basically, it does the same as the Adjust Size icon but you can
  145. resize in many different ways. Once again, the mouse movement defines the
  146. side (corner if Adjust is used).
  147.  
  148. I've also added a different way of shifting the sprite: the sprite remains
  149. fixed and the window travels over it. I have put checks in to make sure the
  150. window doesn't disappear off the screen but the upper edge check is not quite
  151. right yet.
  152.  
  153. Realized that you can at present resize the window so that it disappears off
  154. the screen but fixed it.
  155.  
  156. Made the pointer disappear while the drags were taking place.
  157.  
  158. // VERSION: 0.14a 2-Aug-93
  159.  
  160. I've increased the number of windows allowed to 30.
  161.  
  162. There were a few bugs in the error trapping concerned with memory allocation
  163. and sprite file loading and so I've got rid of these. I've had to rewrite the
  164. file size check since I wrote it using a standard library function and so the
  165. application crashed when the operation failed.
  166.  
  167. // VERSION: 0.15a 2-Aug-93
  168.  
  169. Implemented the stick function (which involved smartening up the poll loop a
  170. little). This is a nice feature (IMO) so I'll dedicate this version to it!
  171.  
  172. // =========================================================================
  173. // RELEASE 1
  174. // =========================================================================
  175. // VERSION: 0.16 4-Aug-93
  176.  
  177. Reimplemented file loading so that only the first sprite in the file was read
  178. in rather than the whole file (Ian Fry). I've also moved towards allowing
  179. other sprites in files to be loaded without ever having to read in the whole
  180. file.
  181.  
  182. Dropped the 'a' from the version number. They are all alphas so far.
  183.  
  184. Read PageSize instead of assuming it was 32K (Ian Fry).
  185.  
  186. Updated the !Help file to make it acceptable for a release.
  187.  
  188. // FUTURE VERSION: 0.17
  189.  
  190. I may decide to have a submenu for "Remove" so that all copies of a sprite
  191. can be removed. May include option on Iconbar menu to remove all sprites.
  192.  
  193. May implement loading from applications. This will make things more interesting.
  194.  
  195. May provide mechanism for grabbing presently cropped section of sprite. To
  196. add to this, I might implement saving a sprite and maybe even an info box for
  197. saying which mode it was defined in and its size,