home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / objectiv / 699 < prev    next >
Encoding:
Internet Message Format  |  1992-12-27  |  6.2 KB
  1. Xref: sparky comp.lang.objective-c:699 comp.windows.misc:1744 comp.sys.next.programmer:7918
  2. Path: sparky!uunet!ogicse!news.u.washington.edu!milton.u.washington.edu!wiml
  3. From: wiml@milton.u.washington.edu (William Lewis)
  4. Newsgroups: comp.lang.objective-c,comp.windows.misc,comp.sys.next.programmer
  5. Subject: Alternative GUI class hierarchies?
  6. Message-ID: <1992Dec27.063724.15059@u.washington.edu>
  7. Date: 27 Dec 92 06:37:24 GMT
  8. Article-I.D.: u.1992Dec27.063724.15059
  9. Sender: news@u.washington.edu (USENET News System)
  10. Followup-To: comp.windows.misc,comp.lang.objective-c
  11. Organization: University of Washington, Seattle
  12. Lines: 95
  13.  
  14.  
  15.    Recently I've been pondering the construction of an object-oriented
  16. GUI toolkit (particularly, using gcc-objc over X, but that detail is 
  17. irrelevant), trying to combine the best attributes of the X intrinsics
  18. and NeXTstep (the two OO GUI toolkits I'm familiar with). One thing that
  19. strikes me as inelegant about both toolkits is the View/Cell
  20. distinction (in X, the Widget/Gadget distinction). Although I understand
  21. the utility of a "lightweight view" for menu selections and so forth,
  22. I've never really liked it. I've thought of two possible solutions.
  23.  
  24.    The first one is really just a workaround. Instead of having
  25. separate hierarchies for "heavyweight" and "lightweight" objects, each
  26. object could select at instantiation time whether it should be lightweight
  27. or not. "Views" ("widgets") who are "lightweight" would have to 
  28. communicate with their closest "heavyweight" ancestor to ask for
  29. events, drawing requests, to determine the (x,y) offset at which
  30. to draw (since in X at least, drawing coordinates are relative to the
  31. destination drawable --- transformation matrices could be very useful
  32. here) and so forth. This would require a little more work on the part
  33. of object authors, however, to handle both cases; and it still wouldn't
  34. simplify the client's structure much (only the display server's). 
  35.  
  36.    The other idea is to divide the object hierarchy even more strictly,
  37. so that any given object can *only* be in one or another subhierarchy.
  38. Basically, I'm thinking of dividing all graphical objects into two
  39. types: those which enclose an area, and those which draw things in
  40. an area. Only area-enclosing objects would receive events from the
  41. display server and mouse. Area-enclosing objects would be allowed to do 
  42. a little drawing, say a frame and a background, but nothing complex 
  43. like text.  Under X, for instance, "enclosing" objects would (possibly) 
  44. have their own window, but "drawing" objects would never have a window.
  45.    Immediately, the question is "but what about objects that both
  46. enclose area, *and* draw things in that area? Like buttons, sliders,
  47. text-boxes, menus ... pretty much everything in fact." For these,
  48. I would have a *third* object which "owns" and manages the enclosing
  49. and the drawing objects. For example, a Button object might own
  50. a SqareEnclosure object and a Text (or SmallImage) object. Only
  51. the enclosure and the text objects would have a visible manifestation. 
  52. The application programmer would interact only with the Button object,
  53. but the Button object would use the other two objects to actually
  54. do its work. This strikes me as having many advantages. Because each
  55. UI element is more modular, it's easy to swap the subparts around:
  56. the same Button class could be used for a button with a text label,
  57. a button with an iconic label, or a button with some application-defined
  58. image, without changing the Button class at all. Similarly, square
  59. buttons, rounded buttons, and hexagonal buttons can be created by
  60. writing a new "enclosure" class and causing the Button to use that
  61. class instead of the "SquareEnclosure". I think this advantage is
  62. applicable to other common UI objects as well.
  63.    The main *disadvantage* is that, in one sense, I've worsened the
  64. original problem: there are now *more* objects floating around in the
  65. application program than there are in the usual scenario! Three objects 
  66. just for a button; more for anything more complex. However, I think this
  67. might not be so bad, because
  68.      - The individual objects are simpler. There are probably also
  69. fewer distinct classes in use at any given time, which could reduce the
  70. RSS of the application.
  71.      - If written well, the Enclosure class could offer much greater
  72. control over server-side resource use. The idea of having each object
  73. select whether it;s lightweight or heavyweight could be used here as well. 
  74.      - Changing the "look" of an application -- say, from Motif-y to
  75. Next-ish to Mac-like --- might involve changing only the Enclosures
  76. and some drawers (like sliders), leaving many application-defined
  77. objects alone. This would have to be designed in, though.
  78.      - In Objective-C, all objects are individually dynamically
  79. allocated. But with some tweaking, it should be possible to allocate 
  80. space for a Button and both of its slave objects in one *alloc() call.
  81. The space would be freed when the Button was freed; the Button would
  82. have the responsibility of calling its component objects' -free methods
  83. before it deallocates itself. ([Object free] would have to be rewritten
  84. to check for this sort of situation, of course.) 
  85.    I think that combining objects in this way would make the increase
  86. in the number of objects much less harmful, since the number of
  87. malloc() blocks would be the same, or even reduced. It would also
  88. improve the locality of reference when responding to events.
  89.  
  90.    So, what do you think? Too many objects? Already been tried
  91. and discarded? Penny-wise and pound foolish? 
  92.    Followups have been directed to comp.windows.misc and 
  93. comp.lang.objective-c. Edit as appropriate.
  94.  
  95.      
  96.  
  97. [P.S.: Some time ago I posted on comp.lang.objective-c about the 
  98. possibility of writing a NextStep-like GUI ObjC toolkit as soon as
  99. gcc 2.3.1 was widely available. I carelessly lost some of the replies,
  100. though... GNU has started work on their own toolkit, but if anyone 
  101. still wants to discuss anything, mail me and I'll try not to lose
  102. your message this time...]
  103.  
  104. -- 
  105. email: wiml@u.washington.edu             |  Home:  Seattle, Washington   |
  106.      (William Lewis)                     |  47 41' 15" N   122 42' 58" W | 
  107. NeXTmail: wiml@ingalls.cs.washington.edu `-------------------------------'
  108.         --*-- Member, Coalition to Preserve Semantic Vacuity --*--
  109.