home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / windows / intervie / 3214 < prev    next >
Encoding:
Text File  |  1992-11-18  |  4.3 KB  |  87 lines
  1. Newsgroups: comp.windows.interviews
  2. Path: sparky!uunet!think.com!mintaka.lcs.mit.edu!kanga.lcs.mit.edu!dave
  3. From: dave@kanga.lcs.mit.edu (David Sternlicht)
  4. Subject: kits and subclassing
  5. Message-ID: <1992Nov18.200805.9174@mintaka.lcs.mit.edu>
  6. Sender: news@mintaka.lcs.mit.edu
  7. Organization: mit x consortium
  8. Date: Wed, 18 Nov 1992 20:08:05 GMT
  9. Lines: 76
  10.  
  11.  
  12. I would like to generate some conversation on Fresco/InterViews kit 
  13. technology.
  14.  
  15. Kits are a very nice idea, however I and other people have ran into
  16. difficulty using them.  To sumarize they are very hard to subclass, defeating
  17. one of c++'s great advantages, the ability to quickly reuse code through
  18. its derivation mechanism.  In my current project I am exploring the obviously
  19. commercially valuble ability  to merge Xt widgets with Glyphs.  My immediate 
  20. problem is that I do  not want the 2 toolkits opening 2 display connections 
  21. to the same display (bad things like X Protocol errors hapen :-).
  22. As it turns out, XOpenDisplay is called from XtAppInitialize, and
  23. in Fresco from the the following execution stack:
  24.  
  25.       Display::open            called from
  26.       SessionRep::init_display  "      "
  27.       SessionRep::init          "      "
  28.       Session::Session          "      "
  29.  
  30. One might reasonably sugest that I simply not use a Session.  This would
  31. be nice except for the fact that WidgetKitImpl::make_kit uses 
  32. Session::instance.  Since I am trying to build a framework that empowers the 
  33. application developer, denying him the use of WidgetKit does not seem like
  34. a good thing.
  35.  
  36. So I say "ok mon, no problem", we have the great c++ language to use here 
  37. and since all important Fresco class methods are virtual, subclass away...
  38. I can either subclass Session/Display to make XOpenDisplay go away, or 
  39. subclass WidgetKitImpl to get rid of make_kit.  Here is where my problems
  40. really begin.  If one chooses to somehow modify Display so that XOpenDisplay
  41. is not called.  The operation would involve changing Session and SessionRep,
  42. as well.  Since SessionRep has no visibility beyond InterViews/session.c
  43. one is essentially reduced to redefining it in its entirety, and then
  44. figureing out what dependencies to other things in the toolkit you may
  45. have broken (like Styles).  Since you now have created a "FooSessionRep" you
  46. must also create a FooSession.  Subclassing Session will not work since
  47. Session's constructor creates a SessionRep, and you are on your way
  48. to that XOpenDisplay you do not want.
  49.  
  50. So after spending alot of time reading source code to figure out whats
  51. going on, you consider the approach of modifying WidgetKit so that
  52. Session::instance is not invoked.  Say one is just worrying about the 
  53. SGI/Motif look and feel.  One must deal with the following classes:
  54. WidgetKit, WidgetKitImpl, SMFKit, and SMFKitImpl, and SMFKit has
  55. a PRIVATE constructor  Again the class definitions for the implenemtations
  56. are inside lib/InterViews/kit.c and smfkit.c.  
  57.  
  58. A number of people besides myself have cited problems in working
  59. with kits.  Since the dificulty of creating  GUI components was
  60. the prime motivation for applying OO technology, particulary inheritance
  61. to the problem domain, the fact that so many Fresco objects, and most
  62. particulary kits are etched in stone is a matter of some concern.
  63. I must now anticipate a responce to this mail which goes some along
  64. the lines of "you dummy, you ignored the foobar feature of the
  65. foobar class that relies on a great feature of c++ that everybody
  66. knows about".  My major point is that one must truly be a wizard with 
  67. private and protected class members and have an intimate knowledge of
  68. the interaction of numerious classes to accomplish ones
  69. goals.  I understand the value of opacity from a maintence point of
  70. view.  But are we sacreficing functionality? Fresco's authors believe
  71. that implementation must be hidden from the user of a library, even
  72. if this hiding conflicts with the users desire to reuse library code.
  73. But will this turn people off?  
  74.  
  75. I realize I have only criticised a wonderfully creative and state of the art
  76. toolkit, and not offered solutions.  Nevertheless these concerns must be
  77. addressed.  One could also bypass kits and go directly to the primitive
  78. classes such as Button and Label but then you lose the Motif or Openlook
  79. look-alike attributes that are importand to the success of this library.
  80.  
  81.  
  82. -- 
  83.             
  84.                 dave sternlicht
  85.                 mit X consortium
  86.                 dave@expo.lcs.mit.edu
  87.