home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 7 / Apprentice-Release7.iso / Utilities / Miscellaneous / CopyPaste 3.3.4 / CopyPaste Tools Sourcecode / Letter to Programmers < prev   
Encoding:
Text File  |  1997-06-11  |  7.4 KB  |  166 lines  |  [TEXT/R*ch]
  1. Dear Mac application programmer,
  2.  
  3. When you first saw the Mac what really amazed you? In the
  4. beginning it was probably the GUI with the icons and menus
  5. and ease of moving files. Later, as you used a Mac to do
  6. real work you were probably impressed with the invisible but
  7. remarkable new ability to copy an item in one program and
  8. paste it in another. This simple and wonderful innovation
  9. opened new worlds in integration and communication on the
  10. personal computer and was later copied by other OS's.
  11.  
  12. The makers of CopyPaste wanted to speak directly with other
  13. developers about that simple ability because its time for
  14. everyone to adhere to apple's guidlines for the clipboard
  15. and its also time to take it to a new level.
  16.  
  17. In those early days Apple gave us various guidelines which
  18. were incredibly far-sighted, but, after all these years we
  19. all know that some areas are a little outdated. Some
  20. problems appeared with the changes to MultiFinder and 32 Bit
  21. addressing, with multitasking, interapplication
  22. communication and other state of the art subjects which did
  23. not exist on the early Macs.
  24.  
  25. Another area where times have chaned is the common
  26. clipboard, the deskScrap. It was always the easiest and most
  27. extensively used means for sharing data between
  28. applications. The Apple guidelines however are somewhat
  29. short-sighted on this important component. In brief the
  30. guidelines prescribe to application developers the
  31. following:
  32.  
  33. 1. If the user switches to another application, then your
  34. application receives a suspend event and should convert its
  35. private clipboard to the deskscrap (the universal
  36. clipboard).
  37.  
  38. 2. Your application should, at the very least, write either
  39. PICT or TEXT data and should be able to read either of these
  40. two.
  41.  
  42. 3. It's the responsibility of the programmer to do as little
  43. computation as possible on receiving a suspend event (when
  44. the program gets switched to the background) to insure the
  45. best general responsivness.
  46.  
  47. With the Mac OS and applying these 3 rules to application 
  48. building changed the face of computing forever. Now people 
  49. expect their applications to behave and communicate effortlessly
  50. between one another. This began in 1984 and now in 1997 Apple
  51. is putting a great amount of attention on two OS's. Both should
  52. be state of the art and should take us further then ever before
  53. in power, ease of use and integration. We believe the clipboard
  54. is one area that could benefit from this renewed attention. 
  55.  
  56. Towards this end we created a program called CopyPaste which
  57. adds 10 clipboards to the Mac. Once a user has grokked one
  58. clipboard and enjoyed it for awhile there comes a time when
  59. they think 'Gee, wouldn't it be nice to copy many items (not
  60. just one) and then go to another application and paste many
  61. items'. CopyPaste does this and more and has been very
  62. popular for that one reason. A comment we get all the time
  63. is that this ability should  be built in. It can be, but its
  64. up to Apple to once again lead the way and also up to all
  65. developers to follow Apples guidelines above and one more.
  66.  
  67. First Consider the following scenario: Say Excel is running
  68. in the foreground and a background process like CopyPaste
  69. wants to act on the content of the clipboard. What do we do?
  70. The only way to get the clipboard of the foreground
  71. application is to send a suspend message which makes the
  72. program think it is being switched to the background. Excel
  73. then goes thru a chain of time consuming changes the
  74. toolbars will be hidden, the controls will be dimmed, the
  75. windows dragbar will be dimmed, any selections will be
  76. removed and finally (and most important for us) the private
  77. clipboard will get converted and put into the DeskScrap.
  78. Then the program gets a resume message and all these steps
  79. et reversed. This can take a few seconds in some large
  80. programs like Excel. This is boring for the user and
  81. annoying. This is entirely UNNECESSARY if a program supports
  82. the deskscrap directly.
  83.  
  84. There are many programs on the market which do offer direct
  85. support. One that everyone knows is SimpleText and the other
  86. known well by most developers is CodeWarrior. If you copy a
  87. selection in either of these programs, the selection is sent
  88. directly to the deskscrap and any background process can
  89. access the data without needing to send a suspend/resume event.
  90. This is fast, efficient and good programming and it is so
  91. simple for all programmers to do. Just insert a PutScrap into your
  92. code.
  93.  
  94. There are programs however which do a terrible job. In them
  95. a selection is copied, then they write fake data to the
  96. deskscrap and only if they get the suspend event then the
  97. fake data is replaced with some correct content (DSIG, CLAP,
  98. WPD2, ...). Dealing with these programs becomes a chore
  99. since each has to be treated in an individual manner thereby
  100. increasing the code and complexity of other applications and
  101. decreasing the overall stability and compatibility of the
  102. interacting applications.
  103.  
  104. Another problem are the types of data which get sent to the
  105. deskscrap. Many programmers think that writing 'PICT' or
  106. 'TEXT' or 'snd ' suffices. That was ok back in 1985 but its
  107. now a decade later and its time to evolve those original
  108. guidelines to support more types of data like 'styl', 'RTF
  109. ', 'MIDI' and/or other formats. 
  110.  
  111. This last problem we've noticed occurs quite often in music
  112. programs. Why don't music programs allow MIDI data to be
  113. copied and then pasted in another application. For instance
  114. the user might want to use the Scrapbook to store MIDI
  115. sequences or perhaps another music program. Users would like
  116. to copy and paste as much as is possible. Lets talk about
  117. and support more formats.
  118.  
  119. If you are not willing to convert your private data into
  120. some common types of data, why not provide a private type of
  121. data for the deskscrap which at least your program can
  122. understand. The DeskScrap could be transfered to another
  123. computer (over the net) on which another copy of your
  124. program is running, or it could be stored in a scrapbook for
  125. later use in your program.
  126.  
  127. Some programs provide plenty of data for the deskscrap but
  128. when this data is pasted again withing their own program its
  129. not able to interpret its own data correctly. So you copy
  130. some text in such a program and get a pict if you paste it
  131. later. Your program should at least be able to copy and
  132. paste the data it creates. If you could examine your code
  133. and implement a more direct support of the deskscrap your
  134. users will benefit and the platform will benefit.
  135.  
  136. In brief, to improve the clipboard usage you should:
  137. - put all necessary data directly into the DeskScrap via PutScrap
  138. immediately whenever the user copies a selection.
  139. - retrieve the data from the DeskScrap whenever the user pastes.
  140. - always anticipate that the DeskScrap data could be changed
  141. in the background, i.e. always check the ScrapInfo fields
  142. for any change before you perform a paste.
  143. - support more data types. Think about what would be useful for 
  144. your users and support as many types as possible being imported
  145. and exported to the deskscrap
  146.  
  147. One final request. Microsoft please have your applications 
  148. follow these guidelines. Apple please take the reins and do
  149. again what you did in 1985 lead us to greater coherence
  150. between applications. Its the future and someone has to do it.
  151.  
  152. If you follow this simple advice working with the clipboard
  153. will become bliss. Your program will be praised by all for
  154. its compatibilty, money will rain down from the heavens and
  155. you will live to a ripe old age admired and respected by
  156. all who know you.
  157.  
  158. Regards,
  159. Your CopyPaste development team.
  160. Peter Hoerster    hoerster@muenster.de
  161. Julian Miller     julian@sierra.net 
  162.  
  163.  
  164.  
  165.  
  166.