Updated typos in 123 readme

git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@7223 ea41ed52-d2ee-0310-a9c1-e6b18d33e121

1 files changed, 22 insertions, 19 deletions

diff --git a/README.123 b/README.123
index 1ab0c4f47..d9472c49a 100644
--- a/README.123
+++ b/README.123
@@ -4,20 +4,20 @@
 
 This file listst the differences between FLTK 1 and FLTK 2 with annotations
 for a possible implementation of FLTK 3. The all new and improved FLTK 3
-needs to be compatible with 1 and 2. It must have a moder API, plenty of
+needs to be compatible with 1 and 2. It must have a modern API, a complete set of
 widgets, lots of options, customization at run-time, but still be easily 
-portable, fast, and of course light.
+portable, fast, and, of course, light.
 
-FLTK 1 has become a nice starting point for the first steps in GUI 
-programming. It runs on al major platform (and on many minor ones
+FLTK 1 has evolved to be a great starting point for the first steps in GUI 
+programming. It runs on all major platform (and on many minor ones
 as well), is small, compact, and easy to use. FLTK 2 was the 
-attempt to continue the success of FLTK 1 with a much cleaber API
+attempt to continue the success of FLTK 1 with a clearer and more modern API
 and many important details improved. Unfortunately many users never 
 made the jump to FLTK 2 and so it not only ended in a crawling slow
 branch, it also became instable and at last unmaintainable.
 
 FLTK 3 sets out to surprise FLTK 1 users and satisfy FLTK 2 junkies.
-It will basically be the improved FLTK 2 API combined with the quite
+It will basically be the improved FLTK 2 API combined with the proven and
 stable innards of FLTK 1. As an extra bonus, FLTK 3 will be compatible
 to 1 and 2. Just prepend your code with the "coding_style" instruction
 and FLTK 3 will do the rest. It is even possible to intermix F1 and 
@@ -34,7 +34,7 @@ on the Forms Library, FLTK 2 is Bill's take on how FLTK 1 should have been.
 This chapter outlines the biggest differences between version.
 
 (1) Coordinate System: FLTK 1 child coordinates are always relative to the 
-window, not as most would expect to the parent. FLTK 2 does the logical 
+window, not as most would expect to the parent group. FLTK 2 does the logical 
 thing and uses group-relative origins. This is somewhat difficult to port
 if we want to stay downward compatible. Fl_Widget will need an additional
 flag indicating absolute or relative coordinates.
@@ -42,10 +42,10 @@ flag indicating absolute or relative coordinates.
 (2) Pulldown Menus: The developers of the Forms Library did not implement
 the idea of hierarchies all the way through. Pulldown menus, which are 
 hierarchical by nature, were instead implemented as a list with lots of
-tricks and cludges to make them usable. FLTK 2 went half way by using the
+tricks and kludges to make them usable. FLTK 2 went half way by using the
 existing Windget/Group relation to create menus, however, menu items are 
 still specialized widgets. For FLTK 3, I would like to allow any widget
-inside a pulldown menu. 
+inside a pulldown menu, using the hierarchical nature of the FLTK base class Fl_Widget. 
 
 (3) Browsers and Tree Views: Browsers in FLTK1 are implemented even worse
 than Pulldown Menus. FLTK 2 solved the issues in a similar way, and here
@@ -53,21 +53,22 @@ again, I prefer the FLTK 2 way very mch, but also would like to extend
 functionality to allow arbitrary widgets as list items. A Tree-like 
 widget comes free with the FLTK 2 concept. FLTK 1 has no such thing and
 even Fluid had to hack the library badly to generate a tree view.
+FLTK 1.3 now comes with Greg's Fl_Tree widget.
 
 (4) Namespaces: this is a minr issue that I include for completeness. FLTK 2
-introduces the ftk namespace, renaming all widgets. FLTK 3 will use the 
+introduces the fltk namespace, renaming all widgets. FLTK 3 will use the 
 FLTK 2 naming scheme and map FLTK 1 class names using typedefs. This is, as
 most things in programming are, a compromise. The "coding_style" function 
 must be used to switch between FLTK 1 and FLTK 2 code. No worries though,
 it's easy and straight forward.
 
 (5) Layout: FLTK 1 uses a top-down approach for widget layout in which the
-parent widget decides about the childs size "resize(x, y, w, h)". In FLTK 2
-any widget can call "layout()" which will query children for their preffered
+parent widget decides about the child's size "resize(x, y, w, h)". In FLTK 2
+any widget can call "layout()" which will query children for their preferred
 size and propagate the information up. This is a great concept that FLTK 3
 should adapt, plus it is compatible.
 
-(6) Ractangle: FLTK 2's base class is fltk::Rectangle. This is nice and
+(6) Rectangle: FLTK uses discrete coordinates and sizes. FLTK 2's base class is fltk::Rectangle. This is nice and
 easy to implement. The API is pretty much the same in both versions.
 
 (7) Styles: FLTK 2 uses a minimal number of styles to define the basic 
@@ -184,8 +185,9 @@ correspond, and how they could be implemented in FLTK 3.
 2: class Dial
 *: should map easily
 
-1: 
+1: class Fl_Box 
 2: class Divider
+*: 
 
 1: class Fl_Double_Window
 2: class DoubleBufferWindow
@@ -194,7 +196,7 @@ correspond, and how they could be implemented in FLTK 3.
 1: class Fl_End
 2:
 
-1: 
+1: Fl_Box 
 2: class EngravedLabel
 
 1: class Fl_File_Browser
@@ -326,8 +328,9 @@ correspond, and how they could be implemented in FLTK 3.
 1: 
 2: class InvisibleBox
 
-1: 
+1: struct Fl_Menu_Item 
 2: class Item
+*: this will be hard to emulate!
 
 1: 
 2: class ItemGroup
@@ -365,7 +368,7 @@ correspond, and how they could be implemented in FLTK 3.
 1: class Fl_Menu_Window
 2: class MenuWindow
 
-1: 
+1: class Fl_Screen? 
 2: class Monitor
 
 1: class Fl_Multi_Browser
@@ -382,7 +385,7 @@ correspond, and how they could be implemented in FLTK 3.
 2: class MultiLineOutput
 *: should map easily
 
-1: 
+1: Fl::lock() 
 2: class Mutex
 
 1: class Fl_Nice_Slider
@@ -408,7 +411,7 @@ correspond, and how they could be implemented in FLTK 3.
 
 1: class Fl_Pack
 2: class PackedGroup
-*: should map easily, FLTK 2 has soem additional functionaity
+*: should map easily, FLTK 2 has some additional functionaity
 
 1: class Fl_Pixmap
 2: