The EW library abstracts differences between various windows systems
and graphics libraries.
Code written above the EW
library requires no knowledge of these differences.
The EW library uses the
Well Behaved Application (WBA) library for
environment and argument handling,
General Purpose Library (GPL)
to provide basic data structures, and the
Operating System Dependency (OSD)
library to abstract differences in operating systems
(other than the window, event, and graphics aspects).
The EW and WDS
systems were carefully separated so that an entirely different set of widgets
could be built over EW.
Therefore, EW has no knowledge of WDS,
WBA has no knowledge of EW,
and likewise of WBA, GPL, and OSD.
WDS extends EW's EW_Widget class to WDS_Widget
to provide some extra functionality that
WDS widgets will expect the other widgets to have.
For example, WDS_Widget
implements run-time type-checking on derived objects.
This is used for look-and-feel inheritance and for use of widgets like
WDS_Scope and WDS_PopUp
who must be identifiable so that other widgets can search the
widget hierarchy for them.
This means you should not use any EW_Widget-derived
widgets with WDS widgets unless they are in fact derived from
WDS_Widget.
Most widgets are fairly self-contained and reside in a matching header
and source file.
Nearly all widgets in the WDS system use the wdsBevelBox()
function to draw their geometry.
WDS widgets will use member functions inherited from EW for their operations.
It is acceptable, and probably neccessary,
for applications to use some of these inherited functions as well.
But, in many cases, an application is capable of corrupting the functionality
of a widget with negligent use of these inherited functions.