home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / acorn / tech / 1016 < prev    next >
Encoding:
Internet Message Format  |  1992-12-14  |  11.3 KB
  1. Path: sparky!uunet!wupost!waikato.ac.nz!aukuni.ac.nz!cs18.cs.aukuni.ac.nz!jwil1
  2. Newsgroups: comp.sys.acorn.tech
  3. Subject: Proposed extensions to External Edit protocol
  4. Message-ID: <1992Dec14.235527.13607@cs.aukuni.ac.nz>
  5. From: jwil1@cs.aukuni.ac.nz (TMOTA)
  6. Date: Mon, 14 Dec 1992 23:55:27 GMT
  7. Sender: jwil1@cs.aukuni.ac.nz (TMOTA)
  8. Organization: Computer Science Dept. University of Auckland
  9. Lines: 251
  10.  
  11. Proposed additions to the External-Edit protocol description
  12.  
  13. There follow some PROPOSED additions to the External Edit protocol, which
  14. should help clear up a few points,as well as add some functionality.
  15.  
  16. I would like any comments you have on these ideas before they are carved
  17. in stone and added to the existing document.
  18.  
  19. I'm also re-writing the External edit documents from scratch to hopefully
  20. make them more user-friendly. The result of this and the above will be posted
  21. in a couple of weeks or so...
  22.  
  23. ---
  24.  
  25. Multi-file-document handling
  26.  
  27. Some packages (e.g. Impression) use a distributed document format which does
  28. not conform to ExtEdit's idea of a 'single datafile'.
  29. It can be seen that placing a WYSIWYG Impression document including graphics
  30. etc. into another document may happen in the future, and therefore it would
  31. be sensible to have some definition laid down to cope with such an event!
  32.  
  33. In such cases, it is up to the designer of the multi-file document to provide
  34. means for the document to be handled as a single entity. With no extra effort,
  35. this can be achieved by never using RAMTransfers - if a document is saved to
  36. disc, then the editor can detect the type and treat it appropriately. In cases
  37. where RAMTransfer is desired, the designer of the data file format must
  38. specify some means by which the data can be transferred as a single "file".
  39.  
  40. ---
  41.  
  42. External edits of External edits!
  43.  
  44. A hypothetical case:
  45. We have an impression document containing a drawfile.
  46. We ExtEdit the drawfile out to Draw
  47. From Draw, we ExtEdit out a sprite in the drawfile to Paint, and a text-area
  48. to Edit.
  49.  
  50. When the data in the Drawfile needs to be returned (by user closing the draw
  51. window or clicking save, or by an EditReturn message), what action should
  52. Draw take?
  53.  
  54. The External Edit protocol is designed to be a "Please edit this data and
  55. tell me when it is complete" system. Thus, no *editor* should attempt to
  56. retrieve data that is being ExtEdit'd from within an ExtEdit document in
  57. order to update the data it returns to it's own client.
  58.  
  59. If the reason for return will allow continued editing (User has saved, or
  60. the EditReturn requests continued editing), then the current drawfile should
  61. be returned as normal; Draw should *ignore* the fact that part of the data
  62. is currently out being edited.
  63.  
  64. However, what should be done if the request demands closure of the editing
  65. session?
  66.  
  67. *  Whatever happens, this should result in closure of all connected sessions.
  68.  
  69. Draw should:
  70.  1 Pop up an error box much ike that for closing an unsaved document:
  71.    "There is unreturned external data: Save/Discard/Cancel".
  72.  
  73.  2 The user clicks one of the buttons:
  74.    a) SAVE
  75.      This should request the return of all ExtEdit data to update the drawfile,
  76.      and then save the drawfile back to the original client.
  77.  
  78.    b) DISCARD
  79.      This should return the current drawfile to the client, and send ABORT
  80.      messages to all related external editors.
  81.  
  82.    c) CANCEL
  83.      Editing continues as normal, giving the user the opportunity to (e.g.)
  84.      save the sprite from paint back into the drawfile, and discard the
  85.      modified edit docment (leaving the drawfile unchanged) before closing
  86.      the drawfile again.
  87.  
  88. My main concerns are that
  89.  * The user doesn't lose all external-edit data without a warning,
  90.  * The drawfile isn't automatically updated by sucking back the text and
  91.    sprite - the user may not want to update the drawfile with the edited
  92.    data, and this could result in unintended corruption of their document.
  93.  
  94. All this means that the user will have to do slightly more of the work
  95. themselves, but at least
  96.  
  97. ---
  98.  
  99. Cursor/selection positioning addition to ExtEdit protocols.
  100.  
  101. Definitions:
  102. A data "unit" is the smallest useful data item represented in a document.
  103.   examples:
  104.     text files: units are characters
  105.     draw files: units are objects
  106.     Sound samples and other binaries: units are byte offsets
  107.  
  108. The "Cursor" is some kind of 'marker' which can be placed at meaningful
  109. unit positions within the document.
  110.   examples:
  111.     text files: The cursor is the caret position
  112.     draw files: The cursor denotes a single draw object (path, textarea, etc)
  113.  
  114. The "Selection" is a group of units that can be described by a range
  115. delimited by two cursor positions.
  116.   examples:
  117.     text files: The selection is a series of adjacent characters
  118.     draw files: The selection can be any contiguous linear sequence of objects
  119.         in the file. This limits the selection slightly, but see below.
  120.  
  121. The imperative of this addition to the External Edit protocol is to allow
  122. positioning of a text cursor in a text document (as this is the most common
  123. case where cursor-positioning would be useful), but it is hoped that the
  124. cursor positioning process can be generalised sufficiently that it is
  125. adequate for other data types as well.
  126.  
  127. My proposal is the following extra message:
  128.  
  129. Message_EditCursor
  130.   R0 = 17
  131.   R1 + 20  Reserved
  132.   R1 + 24  Job handle
  133.   R1 + 28  Flag word
  134.        The following flags are relevant-
  135.          * Adjust selection (NEW flag)
  136.            In some cases (e.g. drawfiles) it is possible to select
  137.            an arbitrary number of arbitrary objects. In these cases,
  138.            this flag will allow an equivalent of 'mouse adjust-selection'
  139.            to take place.
  140.            If this flag is clear, then the selection will be cleared
  141.            and set to the given values (a 'mouse select-selection')
  142.  
  143.          * Read-only flag
  144.            This can be used to alter the read-only status of the file
  145.            during editing (e.g. a compiler could set read-only on the
  146.            file during re-compilation to stop the user being able to
  147.            save the data to an 'open file'.)
  148.            To affect the read-only flag only, set all the new cursor
  149.            values to -1.
  150.  
  151.          * Immediate playback
  152.            Exactly the same as the already-defined flag. This allows
  153.            you to transfer a sound or movie with an EditDataSave, but
  154.            delay playback until after you have selected the region you
  155.            want played with an EditCursor message.
  156.  
  157.   R1 + 32  New absolute cursor position
  158.   R1 + 36  New absolute start-of-selection position
  159.   R1 + 40  New absolute end-of-selection position
  160.  
  161.   R1 + 44  Old cursor          } These are filled in and returned by the
  162.   R1 + 48  Old selection-start } editor if the cursor-positioning is
  163.   R1 + 52  Old Selection-end   } successful (see below).
  164.  
  165. The positions are declared in terms of units. (e.g. text characters, or draw
  166. objects, etc), and are *inclusive*.
  167. Unit numbers specify an object index (1, 2, 3), or a caret position (0 = BEFORE unit 1, 1 = AFTER unit 1/BEFORE unit 2, etc)
  168.  
  169. Special values of cursor/start/end:
  170.   -1 (&FFFFFFFF) indicates "the current value". This allows you to alter only
  171.   one of the three positions. If -1 is used for all three values, you can
  172.   simply read the positions without affecting them.
  173.   In a reply from an editor, -1 indicates an invalid/undefined value.
  174.  
  175.   -2 (&FFFFFFFE) indicates "end of file". This should be used to set any of
  176.   the three values to point to (after) the last unit of the document.
  177.  
  178. Examples:
  179.   start =  1, end  -2:       Select entire document
  180.   start = -1, end = 400:     Alter selection to finish at/after unit 400
  181.   cursor = -1, start = end : Clear selection
  182.  
  183. Reading the cursor value:
  184. Whenever an editor recieves an EditCursor message, it should fill in bytes
  185. 44-56 of the message with the current cursor values, alter it's cursor values
  186. to reflect the new settings as closely as possible, and return this modified
  187. message to the sender. Thus, a message with 'NEW' values of -1, -1, -1 can
  188. be sent by the client to read the cursor only.
  189.  
  190. It won't always be possible to have a defined meaning for selections.
  191. For example, an editor might reply to messages with cursor = <cursor_position>,
  192. start = -1, end = -1, which indicates that either there is no selection or
  193. the editor is incapable of returning a sensible measure of the selection in
  194. these values.
  195.  
  196. An editor is not required to support cursor positioning or selection, but
  197. it is desirable...
  198.  
  199. In some cases, the cursor position could be treated slightly differently:
  200.   e.g. In a text file, the selection and caret positions are clearly defined
  201.        entities, and relate exactly to the values used above. However, with
  202.        Macintosh style cut/copy/paste, setting of selection and cursor are
  203.        mutually exclusive. Therefore it is a good idea to set only the
  204.        selections or the cursor positions at a time. An editor which can only
  205.        support one such selection/cursor at a time should always give priority
  206.        to the selection position (e.g. a compiler could select the line in
  207.        error and also set the cursor to the start of the line - the selection
  208.        is more important)
  209.  
  210.   e.g. In a drawfile, to select a single object you can use start=end. This
  211.        makes the cursor position redundant. In this case, the cursor position
  212.        should be treated differently: It should identify an object which is
  213.        not to be specifically selected, but which should, if possible, be
  214.        displayed in the center of the window by scrolling the draw window.
  215.  
  216. Thus, in any case where the cursor position is redundant, it should be used
  217. to set a 'display position' by identifying the unit which should appear
  218. at the center of the display window.
  219.  
  220. If you are writing an editor, please check out the definition of 'unit' for
  221. that data type in the documents, or contact me. If it is a previously undefined
  222. unit-type, then I can add an official meaning...
  223. The currently suggested meanings are:
  224.   Data:          BYTE offset.
  225.          (This includes data, DOS, utility, module, absolute, etc)
  226.          The cursor position is the same as for text (i.e. you can
  227.          have a caret as well as a selection)
  228.  
  229.   Text:          CHARACTER offset
  230.          (This includes text, obey, command, exec, etc)
  231.          Sorry, but to go to a specific line, you'll have to count
  232.          the number of characters...
  233.          This operates with a caret and a selection.
  234.  
  235.   Drawfile:      } Object/sprite index (i.e. "the 5th object in the file")
  236.   Spritefile:    } These operate with a display-position + a selection.
  237.  
  238.   Sound samples: BYTE offset within the datafile. For stereo samples it will
  239.          be necessary to use 2 cursor positioning messages if you wish
  240.          both channels to be selected. 16 bit samples are also
  241.          accessed bytewise.
  242.          This operates with a display-position and a selection.
  243.  
  244.   Palette file:  Colour index (0..15 for colours 0..15, 16 onwards for
  245.          mouse/border colours, in the order they appear in the file)
  246.  
  247.   Alarm file:    Alarm index
  248.  
  249.   Impression:    I suppose a character offset?
  250.  
  251.   Movie files:   Frame number. A selection indicates the set of frames to be
  252.          played. The cursor position sets the initial frame to be
  253.          diplayed (e.g. cursor 1 could be used to show the title frame
  254.          of a movie, with a selection of 73-168 indicating which
  255.          portion of the movie should be played when the user clicks
  256.          the 'play' button.)
  257.  
  258. -- 
  259. _________________  "I'd like to answer this question in two ways:
  260.   /____ _ _/_ __       First in my normal voice, and then
  261.  // / //_//_ /_/       in a silly, high-pitched whine." (Monty Python)
  262.