Author:jfiat

Date:2014-04-26T17:28:50.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1330 abb3cda0-5349-4a8f-a601-0c33ac3a8c38

documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-introduction.wiki

@@ -1,7 +1,7 @@
 [[Property:title|EiffelVision Introduction]]
 [[Property:weight|0]]
 [[Property:uuid|f964651a-e36d-4e9e-00ea-37803a26373a]]
-The EiffelVision 2 library offers an object-oriented framework for graphical user interface (GUI) development. Using EiffelVision 2, developers can access all necessary GUI components, called [[Widgets|widgets]]  (buttons, windows, list views) as well as truly graphical elements such as points, lines, arcs, polygons and the like -- to develop a modern, functional and good-looking graphical interactive application. 
+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. 
 
@@ -10,7 +10,8 @@ EiffelVision 2 has played a major role at Eiffel Software and provided numerous
 
 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, buttons etc., and apply clearly understandable operations to the corresponding objects. 
+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==
 
@@ -21,29 +22,32 @@ EiffelVision 2 relies on a two-tiered architecture illustrated by the following
 
 
 The two tiers play complementary roles: 
-* At the top level, EiffelVision 2 provides fully portable graphics.
+* 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 a 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'''. 
+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 are added wherever possible. Following is a summary of the other re-engineered aspects of the library: 
+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 '''stone''' (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 stone. 
+* The [[EiffelVision Pick and Drop|Pick-and-Drop]]  mechanism now relies on the Eiffel type system. A '''stone''' (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 stone. 
 *  [[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 mechanism and data structures needed to build advanced user interfaces for deployment on almost all platforms without having to worry about detailed requirements of toolkits.
+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. BUTTON hence becomes <eiffel>EV_BUTTON</eiffel>, etc. }}
+{{note| All class names in EiffelVision 2 are pre-pended with EV_ to avoid name clashes with existing classes.  Thus, <eiffel>BUTTON</eiffel> becomes <eiffel>EV_BUTTON</eiffel>, 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 property. A property can be read-only, which means that it cannot be set by clients of the class.
+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.
 <code>
     text: STRING
 
@@ -54,7 +58,7 @@ When talking about a property of a class, like `text', in fact we are talking ab
         end
 </code>
 
-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, the second to false. This has been done like this because sometimes these enable/disable features have trivial equivalents, for example for feature `enable_visible' a clearer name is `show'. 
+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'. 
 <code>
     is_sensitive: BOOLEAN
 
@@ -72,9 +76,10 @@ Boolean properties have a different convention. Instead of one set-routine, it h
         end
 </code>
 
+
 ==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 <eiffel>interface</eiffel>. 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 <eiffel>_I</eiffel> appended to it. From this implementation-interface, implementation classes inherit to implement platform-specific features. 
+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 <eiffel>interface</eiffel>. 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 "<eiffel>_I</eiffel>" suffix. The implementation classes (with an "<eiffel>_IMP</eiffel>" suffix) then inherit from this implementation-interface class to implement platform-specific features. At run time, the implementation objects (instantiated from these "<eiffel>_IMP</eiffel>" classes) are then polymorphically attached to the to the "<eiffel>_I</eiffel>"-type attributes (typically named "implementation") to provide the platform-specific services.
 
 
 

documentation/current/solutions/iron-eiffel-package-repository.wiki

@@ -4,6 +4,9 @@
 [[Property:uuid|17d54aa0-3d7f-4993-2ad6-423bd0cedd44]]
 {{ReviewRequested}}
 
+'''This documentation has to be updated for 14.05 which brings nice addition'''
+
+
 ==Purpose==
 
 IRON provides an easy-to-use facility for using and sharing libraries of quality Eiffel components, automating many of the tasks involved.
@@ -21,7 +24,7 @@ One application of ECFs is to support libraries installed in different places on
 As projects grow and multiply, the number of these variables adds up quickly.  A dozen or more such environment variables per system is (prior to IRON) not uncommon. Coordinating their use and evolution among a team of programmers can become a challenge.
 
 IRON has made it possible to simplify this scenario dramatically.  For any commonly used library, it suffices to:
-* Install the library on an IRON server.
+* Install the library from an IRON server.
 
 * For any program that uses the library, include in the project's ECF a reference to the library's location <i>in the server</i>, rather than its physical location.