home *** CD-ROM | disk | FTP | other *** search
/ Nebula 1994 June / NEBULA_SE.ISO / SourceCode / MiscKit / Documentation / MiscFindPanel / FAQ.MiscFindPanel next >
Encoding:
Text File  |  1993-10-22  |  9.5 KB  |  205 lines
  1. Frequently Asked Questions about the MiscFindPanel Package
  2.  
  3.             Christopher J. Kane (kane@gac.edu)
  4.  
  5.                        Version 1.1
  6.  
  7.  
  8. This file presents a number of often-asked questions and
  9. comments about MiscFindPanel, and the related categories
  10. and files, and my answers or responses to them.  (And a
  11. few questions and answers I made up myself.)
  12.  
  13. Thanks especially to Scott Anguish (sanguish@digifix.com),
  14. Charles C. Lloyd (clloyd@gleap.sccsi.com), and Don Yacktman
  15. (Don_Yacktman@byu.edu) for asking or inspiring many of
  16. these questions.
  17.  
  18.  
  19.   Topics:
  20.     1. The "non-standard" interface
  21.     2. Having other objects do the searching
  22.     3. The searching code is not in the bundle
  23.     4. SearchableText rather than MiscSearchableText
  24.     5. Separate bundle rather than .bproj
  25.     6. Those translations
  26.     7. Objects other than Text
  27.  
  28.  
  29. ----------------------------------------------------------------
  30. Question 1: The "non-standard" interface
  31. > The find panel offers all the standard features, but doesn't
  32. > present the "standard" interface found in Edit.  Why is this?
  33. > Did you consider making the MiscFindPanel an exact clone of
  34. > the find panel in Edit?
  35.  
  36. That's how it began, of course.  But I made a few changes:
  37.   1. The Find TextField and Replace With TextField are not
  38.      lined up as in a Form.  I didn't see any good reason why
  39.      this had to be, and maximizing the "area to type in"
  40.      seemed more important.
  41.   2. The position of the message text in the Edit find panel
  42.      seemed to be arbitrary--there was no reason to prefer it
  43.      being on the left.  But there _did_ seem to be a good
  44.      reason to move the Replace All Scope radio buttons to the
  45.      left: it associates the matrix moreso with the Replace All
  46.      button, and also reduces the amount of mouse movement
  47.      required after acting in the matrix.  Myself, the only
  48.      reason I operate on those radio buttons is that I am
  49.      immediately going to Replace All.  I very briefly looked
  50.      at having the message text in the center, but that was
  51.      not aesthetically pleasing, and harder for the eye to pick
  52.      out somehow.
  53.   3. The Previous and Next buttons on the German version of the
  54.      Edit panel are translated awfully (well, the translations
  55.      mangle the panel).  I think my translations are sufficient
  56.      and make the panel look better.
  57.  
  58. The biggest (and most often commented on) change is #2, above.
  59. I don't think that the changes are significant enough to cause
  60. confusion.  I think that in the few-hundredths-of-a-second
  61. period, as the user's eyes track horizontally across the panel,
  62. the eye will not be tracking for an empty area of the background
  63. color, but rather for color changes from that of the background:
  64. the square shape of the boxes, the black text, or most likely
  65. (in my opinion), the white dot in the Replace All radio matrix.
  66.  
  67. So it seems to matter less that the Replace All matrix and
  68. friends have been left rotated one place, than that the Replace
  69. All matrix has a similar look to the one in Edit's find panel.
  70. And if a developer _really_ wants the look of the interface that
  71. Edit has supposedly "standardized", she or he can simply modify
  72. the .nib files (though they are not as simple as they appear).
  73.  
  74. I used this same design in an application I wrote (Schematik.app,
  75. a NeXT front-end to MIT Scheme) two years ago, and as of now,
  76. two years and thousands of users later, there has never been
  77. a complaint, nor even a comment, about the "non-standard"
  78. find panel user interface.
  79.  
  80. People are highly adaptable creatures.  How many thousands of
  81. people use NewsGrazer (as an example, sorry Jayson), with its
  82. non-standard command-key usage, every day and live through the
  83. experience?
  84.  
  85. ----------------------------------------------------------------
  86. Question 2: Having other objects do the searching
  87. > Why not integrate the regex and searching functionality into
  88. > the MiscFindPanel?
  89.  
  90. Another NeXT application developer and I, as it happens,
  91. discussed this at length.  He thought the MiscFindPanel should
  92. also have searching functionality.  I disagreed (and implemented
  93. it without that functionality).  There were two reasons I had:
  94.   1. I wanted a generic sort of panel.  I didn't want to
  95.      complicate the developer's job if the developer had a
  96.      different regex package she or he wanted to use (for
  97.      instance).  This is the reason for having a SearchableText
  98.      protocol, too.  I didn't want to leave developers out in
  99.      the cold however, so I included a good set of regex
  100.      routines with the example.
  101.   2. I wanted to follow the general NeXT paradigm for panels;
  102.      and a more general object-oriented one.  Does the SavePanel
  103.      actually save the file?  Does the PrintPanel actually do
  104.      the printing? (Well, no the printer does, but in software...)
  105.      Panels are generally vehicles that users use to have actions
  106.      performed, but which don't actually do them.  (NXHelpPanel
  107.      is something of a special case.)  Thus the MiscFindPanel is
  108.      a vehicle for the user to specify searching parameters, but
  109.      does not do the searching.  A Text object (for instance) is
  110.      best equipped to search the text itself.
  111.  
  112. ----------------------------------------------------------------
  113. Question 3: The searching code is not in the bundle
  114. > Does the regex library get put into the bundle automatically?
  115. > What about putting the regex code in the bundle too?
  116.  
  117. This relates to question #2.  There is no point in including the
  118. regex code with the MiscFindPanel object file, since the
  119. MiscFindPanel doesn't use it.  The Misc_TBMK searching routines
  120. and the SearchText category do not go into the bundle for the
  121. same reason.
  122.  
  123. This non-MiscFindPanel.bundle stuff is provided as a convenience
  124. to the developer, to make the panel a bit easier to use.  But the
  125. decision to use it or not remains with the developer; it is not
  126. gratuitously included in the bundle.  And it's easy enough for
  127. a developer to add the files to a project and have them linked
  128. into the proper place.
  129.  
  130. ----------------------------------------------------------------
  131. Question 4: SearchableText rather than MiscSearchableText
  132. > I was wondering why you hadn't changed the SearchableText to
  133. > have the "Misc" prefix that nearly everything else has....
  134.  
  135. There were a few reasons...
  136.   1. I didn't like the sound of "MiscSearchableText".
  137.   2. Protocol names should be descriptive (I think) of some
  138.      property of itself that an object wants to advertise.  The
  139.      "Misc", being an almost-word in itself, seemed to act as an
  140.      adverb to "Searchable", and seemed to distorted the meaning
  141.      of the name.
  142.   3. Protocol names only conflict with other protocol names.
  143.      From NextDev/Concepts/ObjectiveC/3_MoreObjC/MoreObjC.rftd
  144.      (NS 3.x):
  145.          Unlike class names, protocol names don't have global
  146.          visibility.  They live in their own name space.
  147.      Only class names, function names, non-static global variables,
  148.      and #defines and typedefs in header files need to have the
  149.      "Misc" prefix to avoid the majority of name clashes.  Protocol
  150.      and category name clashes are still possible, but much more
  151.      unlikely.
  152.  
  153. ----------------------------------------------------------------
  154. Question 5: Separate bundle rather than .bproj
  155. > Why is the MiscFindPanel not in a .bproj?
  156.  
  157. Well, I don't know.  Probably because I didn't originally implement
  158. it that way.  I've used subprojects in the past, and have never
  159. been impressed.  I just wasn't inclined in that direction.
  160.  
  161. You shouldn't need to compile the MiscFindPanel.bundle more than
  162. once (per project at least).  Subprojects are useful if you are
  163. doing development on "subsystems".
  164.  
  165. ----------------------------------------------------------------
  166. Question 6: Those translations
  167. > Some of your translations don't seem to be correct...
  168.  
  169. Quite possibly.  Most of my translations are translations taken
  170. from NS 3.0/3.1, others were gotten from semi-informed opinions,
  171. and the rest are "best guesses".  NeXT may not have used the
  172. _best_ translations, but it seems likely that they used the most
  173. _suitable_ one (the length of a translation is one consideration).
  174. And the others are probably comprehensible, even with a mis-
  175. conjugated verb or mis-pluralized noun here and there.
  176.  
  177. I am *very* willing to listen to translation suggestions, and/or
  178. to work with someone on translating the MiscFindPanel to another
  179. language.  Please e-mail me.
  180.  
  181. ----------------------------------------------------------------
  182. Question 7: Objects other than Text
  183. > How about a find panel that works with NXBrowsers or in a Matrix.
  184. > Will MiscFindPanel handle this too?
  185.  
  186. Yes, sort of.  An object must conform to the SearchableText protocol,
  187. but if it does, the MiscFindPanel will work with it.  I created the
  188. SearchableText protocol with Matrixs, selection lists, and, of course,
  189. the Text class in mind.  My goal was to create a general protocol
  190. which any object that had text it wanted to "vend" for searching or
  191. replacing operations could implement.  For a Text-like object, this
  192. is simple.  For a Matrix, a programmer would have to decide how to
  193. map a linear sort of text model to two/three dimensions (depending
  194. on your interpretation of the text in a Matrix).  This is not all
  195. that difficult either, and there is lots of documentation to explain
  196. things.  If you are having trouble, feel free to e-mail me.
  197.  
  198. I'd be interested in implementations of the SearchableText protocol
  199. for NeXT's *Kit classes, as well as others, to be included (with
  200. copyright notices and documentation, as appropriate) in future
  201. releases of the MiscFindPanel package.  Please e-mail me if you
  202. would like to contribute.
  203.  
  204. ----------------------------------------------------------------
  205.