The evolution of EiffelVision
This working document was published on the comp.lang.eiffel newsgroup in 1995. The intention was to illustrate our thinking and directions of development, as well as some of the benefits of the Eiffel way of doing things.
All the products described below as "in progress" were released shortly after the publication of this message. More generally, EiffelVision and the associated libraries (MEL, WEL) have been considerably extended and improved. As a result, a number of comments are not applicable any more, in particular the description of EiffelVision's limitations at the time.
See also: the document describing the new EiffelVision, continuing and improving on previous versions, was released in draft form in October of 1998 and revised in April of 1999.
In the past, announcing some of ISE's product plans on the net has always yielded beneficial feedback from users and colleagues. The present note continues the tradition by discussing quite openly what we are doing with respect to a key element of our technology: the EiffelVision graphical and user interface library. Comments will be welcome.
The EiffelVision library provides a solution to one of the central needs of software developers: a high-level approach to graphical development. In particular, EiffelVision is one of the few products that support both "GUI" programming (managing windows, panels, buttons and other user interface objects) and graphical manipulations (geometric figures - circles, polygons and the like, including complex figures of an arbitrary level of nesting).
EiffelVision is a key element of our technology; all of our current products (e.g. EiffelBench, EiffelBuild, ArchiText) use it, and most of our customers' applications also rely on it. We are putting considerable effort into building the next generation of EiffelVision so that it will continue to support the needs of our customers.
Portability is a key concern in EiffelVision. Even though the product evolved in part from a Motif library, it also supports Windows programming.
Even though we hear frequent siren calls - including on comp.lang.eiffel - of the form "Forget about portability, all we need is a good [fill in some API here, usually Windows] encapsulation", we think it is our duty to Eiffel users, and one of the major attractions of a such a library, to provide a platform-independent solution, even if not all users are concerned about portability yet.
In fact, the relationship between portability and adaptation to specific platforms is not necessarily "either-or". This realization explains the current direction of evolution for EiffelVision.
Taking a critical look at EiffelVision, one may make two comments that at first sight appear contradictory:
For some, EiffelVision is too abstract: they feel that it is not close enough to, say, the Windows API.
For others, EiffelVision is not abstract enough: the library's view of how its users should do things is still influenced by its Motif origins.
Both of these criticisms are to a certain extent justified; but one can answer them without contradiction. It is possible to make EiffelVision:
1. More abstract, by removing anything that is Motif-specific or just Motifish.
2. More concrete, by building platform-specific layers for each of the important APIs: Windows, X/Motif etc.
This is the basis of the new EiffelVision architecture.
Task 1 is the natural evolution of EiffelVision. Cleaned up from some Motif specificities, made more general and more powerful, EiffelVision will be even more simple and intuitive to use, allowing a beginner to put together a graphical application very quickly. The result, of course, will be fully portable.
Task 2 has led to the design of a new library: WEL (the Windows Eiffel Library). WEL is an encapsulation of the Windows graphical API, meant for those developers who are focusing on Windows and want to have access to the entire set of mechanisms of that platform.
Similarly, the Motif-specific part is now encapsulated in a new library: MEL (the Motif Eiffel Library).
EiffelVision, WEL, MEL and similar libraries are not separate developments: the platform-specific parts of New EiffelVision are entirely programmed on top of WEL in the Windows implementation and MEL in the Unix and VMS implementations. So WEL and MEL are not separate developments: they are the platform-specific parts of EiffelVision. The following picture represents the new architecture:
For a user, the rationale for using either library level is clear:
The platform-specific level (WEL, MEL, ...) provides access to all of Windows and most of Motif, at the expense of portability.
The EiffelVision level guarantees portability, but not all platform-specific facilities will be available (although it is likely that any really useful facility which is not present in EiffelVision at a certain stage will find its way into it at a later release, implemented through the native mechanisms on some platforms and emulated elsewhere).
It is also possible to mix both level, for example to take advantage of platform-specific GUI facilities on some platforms while keeping most of the software portable.
This approach provides a comprehensive solution to user needs.
Perhaps the most interesting aspect of WEL is that it does more than just cover the needs of some Eiffel developers for a direct interface to Windows graphical mechanisms. The other audience includes anyone interested in writing graphical applications under Windows simply, safely and effectively - whether or not such a person is already an Eiffel user. To such people, WEL provides a much nicer interface than the other techniques that we know of. This is due to the benefits of the Eiffel approach -- abstraction, inheritance, command classes, reusable components from EiffelBase etc.