Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!stan!garya
From: garya@Solbourne.COM (Gary Aitken)
Newsgroups: comp.windows.x
Subject: Re: Toolkit for Open Look *and* OSF/Motif Look and Feel
Message-ID: <1991Feb27.004047.22743@Solbourne.COM>
Date: 27 Feb 91 00:40:47 GMT
Organization: Solbourne Computer, Inc.
Lines: 70

> >I don't understand why they didn't use constructors, and my first
>guess is that the implementor wasn't completely comfortable with C++

* red face instant defensive maneuver on :-) *
Ouch!  I will not claim to be a C++ guru.  However, one of the more well
known software houses in the country have stated that they like using the
OI source because it stresses C++ better than anything else they have seen.
* red face instant defensive maneuver off *

However, it was for two very specific reasons:

1.	C++ has no way of handling
errors in a constructor.  This is the ONLY way you can do it.  Anyone who
knows otherwise, I would be happy to see an example.

2.	To allow generating two different objects (one OL, one Motif)
depending on the model.  This is because you can't have virtual constructors.

We have since gotten around #2 by extracting the model dependent aspects of
objects into "side" classes, so I guess you could claim bad design.

> OI, while it uses C++ object
> inheritance, still seems pretty C-oriented stylistically

Have you actually used it?  I doubt if anyone who has would make this statement.
Show me some real examples.

> >I don't think it's going to be possible to express the functionality
> > of an "application" generically and yet with enough detail that it
> > could be expressed meaningfully in multiple different look-and-feels.

We've heard a lot of air from people who have never actually tried it, none
from anyone who has.  I was born in Missouri.  Show me.

> >The only way I can think of to do something like it, and do it well,
> >would be to implement the application the same way as the base user
> >interface objects - so that IT also understands each of the possible
> >look-and-feels necessary.

> >I.E. Say you were making a simple "edit" window that needed to be
> >scrollable.  It consists of a vertical string of data and a scroll
> >bar, pasted together in some magic way.  GUI X *requires* that
> >scrollbars be on the right, while GUI Y lets the user decide.  The
> >edit window must understand both of these conventions, and decide
> >between them.

This is trivial.  You specify a VERTICAL scrollbar and let the model put
it on the default location.  This can be overridden by a resource specifying
specifically where to put it.  The application doesn't know or care.

> >  Extending the toolkit to include the objects YOUR
> > application requires makes much more sense to me.

That's what subclassing in C++ is all about.

> We use a bare-bones template based system that fits well into "vanilla"
> C code, for example.  It gives us what we want with a minimum of baggage.

Except it totally falls apart using C++.  You can't use member functions
in callbacks, among other things.  You have to wrap all the callbacks in C
code, preempt the use of the data pointer to pass a structure consisting of
the object, ptr to member function, and data pointer.  The wrapper procedure
has to decipher the structure and make the appropriate callback.  Then you have
to remember to malloc/free that little structure every time you change the
callback.
-- 
Gary Aitken

Solbourne Computer Inc.    ARPA: garya@Solbourne.COM
Longmont, CO               UUCP: !{boulder,sun}!stan!garya