home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / windows / openloo / 4878 < prev    next >
Encoding:
Text File  |  1992-12-21  |  3.0 KB  |  84 lines
  1. Newsgroups: comp.windows.open-look
  2. Path: sparky!uunet!uuhelio!jpf
  3. From: jpf@uuhelio.uucp (Jeff Francis)
  4. Subject: Re: A Better Programming Interface for OLIT?
  5. In-Reply-To: jipping@cs.hope.edu's message of Fri, 18 Dec 1992 14:51:24 GMT
  6. Message-ID: <JPF.92Dec18232713@uuhelio.uuhelio>
  7. Sender: jpf@uuhelio.uucp (Jeff Francis)
  8. Organization: HelioCentric Software
  9. References: <1992Dec18.145124.28204@cs.hope.edu>
  10. Date: Sat, 19 Dec 1992 05:27:13 GMT
  11. Lines: 71
  12.  
  13. "finer grain" sounds good to me!  For example, in XView the "Panel
  14. Item Label: Panel Item Value" is easy to setup.  In OLIT one is
  15. constantly having to create a Caption widget, label it, and then
  16. create and manage a value widget kid inside it.  Pain.  
  17.  
  18. To answer your question "Is there a better programming interface for
  19. OLIT?"  Yes, try Wcl.  It's not really another API but it is a much
  20. cleaner way to wip together Xt-based interfaces.
  21.  
  22. While we're on the subject of the crufty OLIT API I'll add a few
  23. comments.  Here's some OLIT Widget/API complaints.
  24.  
  25. 1. How about the overall lack of a naming prefix.  I previously
  26. used Motif which always uses the Xm prefix for naming things.  OLIT is
  27. rather loose in naming things.  Sometimes they use Ol... and sometimes
  28. they don't.
  29.  
  30. 2. Then there is the OlDefine type that adds little value.  For
  31. example, the AbbrevMenuButtonWidget's XtNlayoutType is of type
  32. OlDefine and might take on the values:
  33.  
  34. [0-18 deleted]
  35. #define OL_FIXEDCOLS        19
  36. #define OL_FIXEDROWS        21
  37. [22-150 deleted]
  38.  
  39. Why not something more explicit like:
  40.  
  41. typedef enum {
  42.     OL_FIXEDCOLS,
  43.     OL_FIXEDROWS
  44. } XolLayoutType;
  45.  
  46. Other Widgets do much of the same.  Sure, it might have taken
  47. the OLIT team a day or two more to code things this way.  But, it
  48. could save OpenLook.h readers hours of wondering.
  49.  
  50. 3. Then there is the ScrollingList.  What a cleaver idea making the
  51. insert/delete routines resources.  What a pain it is to use them.  My
  52. first OLIT to-do was to write the list routines that the OLIT team
  53. should have.  And where's the glyph support that XView has.
  54.  
  55. 4. Ever try putting a child in a DrawArea and then performing a
  56. geometry operation on the child?  Crash.
  57.  
  58. 5. Then there is OlAddCallback.  Some OLIT manpages say to use it
  59. versus XtAddCallback.  man OlAddCallback yields, "No manual entry for
  60. OlAddCallback".  What does OlAddCallback do?.  How about providing
  61. _all_ the Xt manpages.
  62.  
  63. 6. Anyone care to give-up the secret of the Category widget or any of
  64. the other undocumented classes?
  65.  
  66. 7. The Form widget.  Yes, it's a four letter word starting with 'F'.
  67.  
  68. 8. ... that's enough for now.
  69.  
  70. Anyway, I sure would like to see Jim Mukerjee, SunSoft's Windows
  71. Toolkits Product Manager, follow-up on his comment,
  72.  
  73.     We strongly encourage developers to use OLIT for any NEW
  74.     applications that are being developed to take advantage of many new
  75.     features and functionalities, and maintain compliance with the rapidly
  76.     evolving STANDARDS for GUI development.
  77.  
  78. Jim, how about a word or two on the "many new feature and
  79. functionalities"?  Or will we need to wait for OpenWindows 4.0?
  80.  
  81.  
  82. -- 
  83. Jeff Francis, HelioCentric Software, uunet!uuhelio!jpf, (515) 232-1300
  84.