[[Property:title|EiffelVision Introduction]] [[Property:weight|0]] [[Property:uuid|f964651a-e36d-4e9e-00ea-37803a26373a]] The EiffelVision 2 library offers an object-oriented cross-platform framework for graphical user interface (GUI) development. Using EiffelVision 2, developers can access all necessary GUI components, called [[Widgets|widgets]] (buttons, windows, list views, etc.) as well as truly graphical elements such as points, lines, arcs, polygons and the likeā€”to develop a modern, functional and professional graphical interactive application. EiffelVision 2 has played a major role at Eiffel Software and provided numerous Eiffel projects with a powerful, portable graphics development platform. EiffelStudio is totally reliant on EiffelVision 2 for its graphical elements and overall interaction with the user. ==Scope== The EiffelVision 2 library addresses all the major needs of developers of systems supporting modern graphical interfaces. EiffelVision 2 runs on Microsoft Windows and all major variations of Unix (including Linux). All versions are fully source-compatible: with only a recompile, applications will run on every supported platform with the native look-and-feel. EiffelVision 2 provides an effective way of building advanced graphical applications using user interface standards and toolkits (such as Microsoft Windows and GTK) without having to learn the details of the toolkits. Instead, you can use EiffelVision 2 to work entirely in terms of high level abstractions representing windows, buttons, labels, graphical figures, menus, etc., and apply clearly understandable operations to the corresponding objects. ==Architecture== EiffelVision 2 relies on a two-tiered architecture illustrated by the following figure. [[Image:vision2--figure1]] The two tiers play complementary roles: * At the top level, EiffelVision 2 provides a fully portable graphics library. * At the lower level, platform-specific libraries cover the graphical mechanisms of graphics platforms such as Windows and GTK. The lower tier serves for the implementation of the upper tier, but can also be used independently. For example [[WEL]] has had resounding success with Windows developers who need an advanced mechanism for building Windows-specific graphical applications, taking advantage of every facility of the Windows API (Application Programming Interface) and of the Eiffel approach, but do not need portability on the client side. The GEL library is a '''wrapper''' library, automatically generated from the entire GTK API by a tool named '''The Gote Converter'''. ==Features== As stated before, the library has undergone some drastic changes since the previous release. Names have been changed to improve consistency. Contracts have been added wherever possible. The following is a summary of the other re-engineered aspects of the library: * Taking full advantage of the '''agent''' mechanism of Eiffel, [[uuid:fc32d1b5-72d6-2955-18fd-bce988ed8323|events]] are now triggered through '''action sequences''' (lists of actions) that will be executed in order. This system does not require separate classes to be written for each event, however the command pattern can still be used if desired. * The [[EiffelVision Pick and Drop|Pick-and-Drop]] mechanism now relies on the Eiffel type system. A '''pebble''' (some transportable object) is now any Eiffel class and can always be dropped on a widget that accepts the type (or a more general type) of that pebble. * [[Containers|containers]] ( [[Widgets|widgets]] that contain other [[Widgets|widgets]] ) are now derived from [[EiffelBase]] classes. For example you can now insert [[Widgets|widgets]] in any position and iterate over them. ==Design== EiffelVision 2 provides programmers with high-level classes that provide all mechanisms and data structures needed to build advanced user interfaces for deployment on almost all platforms without having to worry about detailed requirements of of those platforms (toolkits). The abstract design has been derived from an analysis of user interfaces. Therefore we have classes with names like MENU, WINDOW, BUTTON, LINE or POLYGON. The features of these classes are simple, clearly defined properties or commands, like the feature `minimize` (a command) on WINDOW or `text` (a property of type STRING) on BUTTON. {{note| All class names in EiffelVision 2 are pre-pended with EV_ to avoid name clashes with existing classes. Thus, BUTTON becomes EV_BUTTON, etc. }} ==Properties== When talking about a property of a class, like `text`, in fact we are talking about multiple features. One is a query of the state of the property, in this case simply the query `text`. The other is the set-routine, which is by convention named `set_text` taking exactly one argument of the type of the property. A property can be read-only, which means that it cannot be set by clients of the class. text: STRING set_text (a_text: STRING) ... do ... end Boolean properties have a different convention. Instead of one set-routine, it has one enable-routine and one disable-routine. The first one sets the property to true, and the second to false. This has been done this way because sometimes these enable/disable features have trivial equivalents, for example for feature `enable_visible` a clearer name is `show`. is_sensitive: BOOLEAN enable_sensitive ... do ... end disable_sensitive ... do ... end ==Implementation== For flexibility, EiffelVision 2 is built using the bridge pattern. This means that every platform-dependent component of the library consist of two classes, plus an implementation class for each platform (currently two). One is the interface. All the features of interfaces do nothing except delegate the call to the implementation object which is coupled to it. This object has the static type of the implementation-interface with the name of the interface class, with an "_I" suffix. The implementation classes (with an "_IMP" suffix) then inherit from this implementation-interface class to implement platform-specific features. At run time, these platform-specific implementation objects (instantiated from the "_IMP" classes) are then polymorphically attached to the to the "_I"-typed attributes (typically named "implementation") to provide the platform-specific services. {{SeeAlso| The book titled ''Design Patterns: Elements of Reusable Object-Oriented Software'' by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, contains a complete description of the Bridge Pattern.}}