only get resources can be done through direct interface, and a
precaution must be taken to provide direct interface (methods) for
those resources which are stored in the "native" form.

setting resources should be in general done through SetValues to
ensure that the semantics are preserved, even from within class
method, which has direct access to the widget's fields

q: <Create> triggers for children not for the widget, why ? ok
apparently create notify reports children too, we don't get the widget
itself because it's too late in the constructor.

q: subresources requires  both a name and a class_name, as result
there appears to be two widgets (and two classes, which is ok) between
its parent and the resources (both widgets can have the same name).


the Initialize action has to be defined for each new C++ widget
because the we cannot use virtuals and in Core we dont know the actual
widget's class.

one can built a totally new set of widgets just based on Xt : no need
to have interface to Xt's classes; some functionality is not
accesible: e.g. we need Layout widget which accepts all geometry
requests, in general geometry managers cannot be built in C++ ?


experience with this interface may help in the design of a new C++
intrinsics.

drawback: methods have to be public for the callbacks and action
routines to be able to access them.

style: need to cast in callbacks and actions, also when the results of
calls like Parent() are used, because of lack of virtual functions (
but in fact virtuals wouldn't help, because one cannot define all
possiblr interfaces, it's due to static typing)

Most of the toolkit classing functionality can be achieved without
introducing the second class class hierarchy as in Xt. The result is
more natural C++ environment. It shows that the design of Xt is very
good. The experience with this interface, can be very valuable in
designing a new C++ based Intrinsics, which while removing the
limitations of this interface would retain the strength of the Xt
toolkit library.

Can we get away with the need of subclassing in C?
Problem with geometry management:
Cannot replace class methods (?), because other subclasses and widgets
may rely on them; maybe envelope them ? : how to determine when to use
the original Geometry manager ? : use extensions ? YES YES YES

The core widget defines an xt++ extension and an interface to it. The
extension record contains all the class methods of Core. The c++
interface defines a set of class methods which just simply envelope
the original methods of Core. The interface allows any subclasses to
replace the original method with their own method (which can also
envelope the original method). the extension record contains also the
class name and the superclass name ?

Similar extension rec is created for constraint and other Xt classes.

Drawback: memory usage.

Issues here:
- handle geometry
- class initialization
- resources (set/get values) : can it be made generic ?
	have the resource pointer ?

Problem: how to handle C++ subclasses of C subclasses (widgets),
e.g. Label. Can it be made generic.

Problem: XtGetSubresources: is the requirement that both Class and
name be specified ( we want to specify only Class) ? If it's not in
the Xt spec, maybe the implementation can be changed (and eventually
spec).

Use get/set_values_hook Core method ?

q: registering resources converters ?

destroying widgets on the stack: the test for stack allocation should
be rather in the C++ interface and not in the Intrinsics
implementation.

Sizes:
the sizes of widgets in C++ and Xt have to be the same. Conditional
compilation, like in the case of CommandWidget may lead to errors.
In the C world it affects only widget writers (subclassing); in the
C++ world it affects also clients.

Alignment:
// we have to use the C approach because of the alignment of doubles
// if PannerPart is compiled as a separate structure additional padding
// is added in this structure because some doubles don't fall on the 8 byte
// boundary.
// if PannerWidget is a simple subclass of Simple those doubles do fall on the
// 8 byte boundary and no padding is necessary, and the C++ class doesn't map
// into C struct
It affects only subclass writers, and may be considered an
implementation detail.


Since C++ subclasses use one copy of Xt class, there are some
problems:
- there is one name space for action procs: potential fro clashes !