🚀 go-pugleaf

I would like to generate some conversation on Fresco/InterViews kit 
technology.

Kits are a very nice idea, however I and other people have ran into
difficulty using them.  To sumarize they are very hard to subclass, defeating
one of c++'s great advantages, the ability to quickly reuse code through
its derivation mechanism.  In my current project I am exploring the obviously
commercially valuble ability  to merge Xt widgets with Glyphs.  My immediate 
problem is that I do  not want the 2 toolkits opening 2 display connections 
to the same display (bad things like X Protocol errors hapen :-).
As it turns out, XOpenDisplay is called from XtAppInitialize, and
in Fresco from the the following execution stack:

      Display::open            called from
      SessionRep::init_display  "      "
      SessionRep::init          "      "
      Session::Session          "      "

One might reasonably sugest that I simply not use a Session.  This would
be nice except for the fact that WidgetKitImpl::make_kit uses 
Session::instance.  Since I am trying to build a framework that empowers the 
application developer, denying him the use of WidgetKit does not seem like
a good thing.

So I say "ok mon, no problem", we have the great c++ language to use here 
and since all important Fresco class methods are virtual, subclass away...
I can either subclass Session/Display to make XOpenDisplay go away, or 
subclass WidgetKitImpl to get rid of make_kit.  Here is where my problems
really begin.  If one chooses to somehow modify Display so that XOpenDisplay
is not called.  The operation would involve changing Session and SessionRep,
as well.  Since SessionRep has no visibility beyond InterViews/session.c
one is essentially reduced to redefining it in its entirety, and then
figureing out what dependencies to other things in the toolkit you may
have broken (like Styles).  Since you now have created a "FooSessionRep" you
must also create a FooSession.  Subclassing Session will not work since
Session's constructor creates a SessionRep, and you are on your way
to that XOpenDisplay you do not want.

So after spending alot of time reading source code to figure out whats
going on, you consider the approach of modifying WidgetKit so that
Session::instance is not invoked.  Say one is just worrying about the 
SGI/Motif look and feel.  One must deal with the following classes:
WidgetKit, WidgetKitImpl, SMFKit, and SMFKitImpl, and SMFKit has
a PRIVATE constructor  Again the class definitions for the implenemtations
are inside lib/InterViews/kit.c and smfkit.c.  

A number of people besides myself have cited problems in working
with kits.  Since the dificulty of creating  GUI components was
the prime motivation for applying OO technology, particulary inheritance
to the problem domain, the fact that so many Fresco objects, and most
particulary kits are etched in stone is a matter of some concern.
I must now anticipate a responce to this mail which goes some along
the lines of "you dummy, you ignored the foobar feature of the
foobar class that relies on a great feature of c++ that everybody
knows about".  My major point is that one must truly be a wizard with 
private and protected class members and have an intimate knowledge of
the interaction of numerious classes to accomplish ones
goals.  I understand the value of opacity from a maintence point of
view.  But are we sacreficing functionality? Fresco's authors believe
that implementation must be hidden from the user of a library, even
if this hiding conflicts with the users desire to reuse library code.
But will this turn people off?  

I realize I have only criticised a wonderfully creative and state of the art
toolkit, and not offered solutions.  Nevertheless these concerns must be
addressed.  One could also bypass kits and go directly to the primitive
classes such as Button and Label but then you lose the Motif or Openlook
look-alike attributes that are importand to the success of this library.


-- 
			
				dave sternlicht
				mit X consortium
				dave@expo.lcs.mit.edu