WINGs: ran spell checker on the NEWS file

The command used was:
  aspell --lang=en_GB check WINGs/NEWS

Signed-off-by: Christophe CURIS <christophe.curis@free.fr>

WINGs/NEWS

@@ -223,8 +223,8 @@ Double buffering
 ----------------
 
 To avoid flickering caused by redrawing the widgets on Expose events, a
-double buffering tehnique was implemented for most of the widgets.
-This flickering effect has gotten more vizible with the introduction
+double buffering technique was implemented for most of the widgets.
+This flickering effect has gotten more visible with the introduction
 of antialiased fonts. If with normal text one can redraw the text over the
 old one over and over again without any degradation of the text (new pixels
 simply overwrite old pixels), with antialiased text the situation is
@@ -236,7 +236,7 @@ The double buffer is implemented to solve this issue.
 This is a change that that will be automatically available for any WINGs
 applications and will require no change in the existing code.
 However there is an exception from this in case of WMList if you delegate
-the drawing of items to userspace (read below for the compelte details).
+the drawing of items to userspace (read below for the complete details).
 
 
 *** Mon Oct 14 22:07:42 EEST 2002 - Dan
@@ -244,10 +244,10 @@ the drawing of items to userspace (read below for the compelte details).
 WMList change
 -------------
 
-In case of WMList there is the posibility to delegate the drawing of the
+In case of WMList there is the possibility to delegate the drawing of the
 list items to the application that is linked with WINGs, and this code will
 not be inside the WINGs library, but in userland. Since we use the double
-buffering tehnique in this case too (to allow all widgets based on WMList
+buffering technique in this case too (to allow all widgets based on WMList
 and the ones that draw their list items by themselves to benefit from the
 double buffering advantage automatically), we no longer pass the window to
 the user code doing item drawing, but instead pass this pixmap in which we
@@ -276,7 +276,7 @@ This change is required to support extending WMFont to allow it to handle
 antialiased fonts through the XFree86 Xft2 extension.
 
 This also has the advantage of hiding low level X11 details and use WINGs
-internat objects instead.
+internal objects instead.
 
 To fix your old code to work with the new WINGs API you need to replace the
 GC passed to WMDraw***String() in your code with a WMColor*.
@@ -343,7 +343,7 @@ WMSendConnectionData() can return 3 values: -1, 0, 1
 
 -1 - means that the connection has died. you should stop sending data and
      close the connection ASAP.
- 1 - means that the data was succesfully sent
+ 1 - means that the data was successfully sent
  0 - means that the data (or part of it) was not sent. however, it was saved
      in a queue and the library will try to send it later when possible.
 
@@ -352,14 +352,14 @@ on, until the return value of such a send call will be 0.
 After it returns 0 you can continue sending, however, the data will not be
 sent over the connection because the operating system cannot accept any more
 data for the moment. Instead it will be queued inside the library, making your
-program's memory footprint increase. If the ammount of data you need to
+program's memory footprint increase. If the amount of data you need to
 send is limited and not too big, this shouldn't be a problem, because your
 data will be queued and sent when the operating system will notify the
 library that sending is possible again.
 If this is the case you can just ignore the output of WMSendConnectionData()
 and not set a callback for canResumeSending.
 
-However, if the ammount of data you have to send is undetermined and you
+However, if the amount of data you have to send is undetermined and you
 also want to keep a small memory footprint for your program (so that it
 won't grow until it uses all your available memory ;) ), you will have to
 stop sending data over the connection as soon as WMSendConnectionData()