home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / acorn / tech / 1223 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  4.9 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: Re: new template format
  4. Message-ID: <1993Jan11.013252.13682@cs.aukuni.ac.nz>
  5. From: jwil1@cs.aukuni.ac.nz (TMOTA)
  6. Date: Mon, 11 Jan 1993 01:32:52 GMT
  7. Sender: jwil1@cs.aukuni.ac.nz (TMOTA)
  8. Organization: Computer Science Dept. University of Auckland
  9. Lines: 104
  10.  
  11. I shouted:    ;-)
  12. >> NO! You *must* use *tags* for icons!
  13.  
  14. >I agree that using tags for icons is a good idea.  But if you are only using
  15. >tags for referring icons you lose information about the icon overlap (Dick
  16. >Alstein also noticed this).  This is eg. very important when you are using
  17. >certain 3D icons.
  18.  
  19. I disagree. I think you are talking about overlap as in "this icon is in
  20. front of that one". This can still be achieved, as the icon numbering that
  21. we are currently stuck with gives you that, and it is implicit in the
  22. order of storage of icons in the file.
  23.  
  24.  
  25. >Therefore I suggested to include also an icon-number together with each
  26. >icon definition.  This icon-number is in fact totally invisible for the
  27. >Glass editor user and will define the icon order in the window definition.
  28.  
  29. In fact, the icon number is implicit in the file-storage. This means that
  30. there is a restriction on the user program creating WIMP icons in a
  31. sequential pass through the icon list in the file, and that the editor
  32. allows you to alter the order with "move forward/back" and "put to front/back"
  33. operations, just like in Draw.
  34.  
  35. >This system allows the user to move the icons.  However, when we want to
  36. >allow user to create new icons or to delete icons (do we want that ?), an
  37. >icon renumbering has to happen, so we're back to point zero.
  38.  
  39. No. The important thing about the icon ordering is only the *relative*
  40. order, i.e. higher-numbered icons are in front of lower-numbered ones.
  41. If we delete icon 4, then all following icons move down one place in the
  42. file, but they all hold the same *relative* positions. When moving an icon
  43. forward or back, you simply swap it with the icon below/above it, thus only
  44. changing the order of the 2 icons you are working on. No problem.
  45.  
  46. >Maybe a better way could be : if there is an icon which has to be absolute in
  47. >front of certain other icons, it can have a list of their icon names somewhere
  48. >in this icon definition.
  49.  
  50. No need. You don't have this kind of feature in a drawfile, do you? But you
  51. still manage to get the correct stacking order.
  52.  
  53. Note also that meta-icons (a combination of several normal WIMP icons to
  54. create special things such as a "volume-slider" icon) will have a special
  55. order within the meta-icon, so will always appear in the correct order.
  56.  
  57. ...
  58.  
  59. >Another point I would like to raise is : are we going to support Acorn's
  60. >Help application by defining a help string in each window/icon and menu entry
  61. >(it should also be language independant) ?
  62.  
  63. What about the way I support help in DSEdit II?
  64. This calls a generic (program-wide) event handler for help requests, and
  65. creates a tag of the form
  66.   "Window-template-name.icon-number"
  67. e.g.
  68.   mainwindow.3    - icon 3 in mainwindow
  69.   mainwindow.-1   - window background
  70.  
  71. which is passed to the DeskLib Msgs code to get the message.
  72. If no message is found, it returns no help.
  73.  
  74. This means that the program generates a standard help request to the message
  75. system, and has no need of knowing about specifics of which messages
  76. are/are not available. The message system allows message definitions like:
  77.  
  78.   mainwindow.-1: This is the main window
  79.   maintool.-1: This is the main tool window
  80.   sound.3: This is icon number 3 in the sound window
  81.  
  82.   sound.*: This is anything in the sound window
  83.   main*.4: This is icon 4 in either the main window or main tool window
  84.  
  85. etc.
  86.  
  87. So you can put in help for any icons you feel like:
  88.   dialogue.0: Click here to start this operation
  89.   dialogue.1: Click here to abort
  90.   dialogue.7: Isn't this pretty?
  91.  
  92. ...with a default for any other area of the same window:
  93.   dialogue.*: Point somewhere more interesting!
  94.  
  95. I can completely change the level of help given by DSEdit by simply editing
  96. the messages file: No re-compilation is necessary!
  97.  
  98. Obviously, if icons also had text-based tags, this would become even nicer:
  99.   dialogue.okbutton: Click here to crash your computer!
  100.  
  101. This way is also better, because you can have multiple files for different
  102. languages and stuff. Defining these messages within the template editor
  103. would be too restrictive (though it can use the ExtEdit protocol to allow
  104. you to more conveniently edit such message files in a text editor...)
  105.  
  106. And also, the help can be left until the end of program development to
  107. save you re-writing it every time you make any changes!
  108.  
  109. (Oh, and another thing that's nice with DSEdit's help system is that Msgs_
  110. allows me to load multiple files, so the 10kB of helptext is only actually
  111. loaded when the first helprequest is recieved. This is another advantage of
  112. having a good, centralised, generic, help handler...)
  113. -- 
  114. themasterofthearcanejwil1@cs.aukuni.ac.nzthismessagewassentonrecycledelectrons
  115.