home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / windows / misc / 1749 < prev    next >
Encoding:
Internet Message Format  |  1992-12-31  |  3.6 KB
  1. Xref: sparky comp.windows.misc:1749 comp.lang.objective-c:712
  2. Path: sparky!uunet!crdgw1!rpi!gatech!usenet.ins.cwru.edu!agate!doc.ic.ac.uk!uknet!yorkohm!ian
  3. From: ian@ohm.york.ac.uk (I Stephenson)
  4. Newsgroups: comp.windows.misc,comp.lang.objective-c
  5. Subject: Re: Alternative GUI class hierarchies?
  6. Message-ID: <1992Dec31.152528.4576@ohm.york.ac.uk>
  7. Date: 31 Dec 92 15:25:28 GMT
  8. References: <1992Dec27.063724.15059@u.washington.edu>
  9. Sender: ian@ohm.york.ac.uk (I Stephenson)
  10. Reply-To: ian@ohm.york.ac.uk
  11. Organization: Electronics Department, University of York, UK
  12. Lines: 63
  13.  
  14. In article <1992Dec27.063724.15059@u.washington.edu>  
  15. wiml@milton.u.washington.edu (William Lewis) writes:
  16. > 
  17. >    Recently I've been pondering the construction of an object-oriented
  18. > GUI toolkit (particularly, using gcc-objc over X, but that detail is 
  19. > irrelevant), trying to combine the best attributes of the X intrinsics
  20. > and NeXTstep (the two OO GUI toolkits I'm familiar with).
  21. > 
  22. ...
  23. > 
  24. >    So, what do you think? Too many objects? Already been tried
  25. > and discarded? Penny-wise and pound foolish? 
  26. >    Followups have been directed to comp.windows.misc and 
  27. > comp.lang.objective-c. Edit as appropriate.
  28. > 
  29. >      
  30.  
  31. A few weeks ago I finally took the plunge, and began work on porting my beloved  
  32. NeXTStep program to X. (As I'm sure you'll all understand) the thought of  
  33. moving back to pure C was abhorrent, and so I set about writting a minimal set  
  34. of objects which would allow me to port a program (or more specifically my  
  35. program) between NS and X. I figure Obj-C will spread faster then NS (irritated  
  36. comment about GNU's runtime development), so I should gain something from the  
  37. port.
  38.  
  39. Problem #1 I know very little of X. This is not simply ignorance - this is a  
  40. carfully cultivated scheme over the last four years to avoid X at every  
  41. opportunity.
  42.  
  43. Solution - The Plan 9 compatability library! The Unix version of SAM (the plan9  
  44. editor) includes a library to provide some very primitive operations on a basic  
  45. window. I see no X :-). These are of the draw line, plot point level. This is a  
  46. pain for normal programming but ideal for my purposes (except that it puts the  
  47. origin at the top left!)
  48.  
  49. My initial ideas were to write something very close to NS. However I soon  
  50. realised that I don't need anything as complex. Rather than having a complex  
  51. scheme of heavyweight views, everything is light weight, and plots directly  
  52. onto the screen bitmap (with suitable clipping operations), which is held by  
  53. the XApp object (itself a subclass of XView). This of course means that every  
  54. view object has to be able to redraw itself on request, but this is less of a  
  55. problem using obj-c than it would be otherwise. The advantage is that the  
  56. classes are very portable, as they make use of only very primative operations  
  57. on a single bitmap.
  58.  
  59. Using this I've been able to build buttons, sliders, a primative text field, a  
  60. responder heirachy, menus and modal panels. Within methods drawing is still  
  61. done using plan9 primatives. This is something I may address in the future. I'm  
  62. just in the process of considering the port of actual code. Details of the  
  63. ported code will change, but at least the basic structure will remain.
  64.  
  65. My system is far more primative than the sort of thing you're talking about  
  66. building, but it is sufficient for my purposes. Obj-c does make this sort of  
  67. thing practical - I wouldn't have touched X previously, but I'd now be happy to  
  68. develop code using a toolkit like this. A small amount of code goes a VERY long  
  69. way.
  70.  
  71. Just some of my experiences, that I thought I'd offer.
  72.  
  73. Ian Stephenson
  74. Adaptive systems Engineering
  75. Dept of Electronics
  76. Univeristy of York
  77.