[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    developer.kde.org/documentation/library/kdeqt/kde3arch
From:       Rob Buis <rwlbuis () xs4all ! nl>
Date:       2003-04-12 19:01:19
[Download RAW message or body]

CVS commit by buis: 

Typo fixes.


  M +5 -5      devel-binarycompatibility.html   1.8


--- developer.kde.org/documentation/library/kdeqt/kde3arch/devel-binarycompatibility.html  #1.7:1.8
@@ -18,8 +18,8 @@
 <p> If a program needs to be recompiled to run with a new version of
 library but doesn't require any further modifications, the library is
-<b> source compatible</b>
+<b> source compatible</b>.
 
 <p> Binary compatibility saves a lot of trouble. It makes it much
-easier to distribute software for a certain plattform. Without
+easier to distribute software for a certain platform. Without
 ensuring binary compatibility between releases, people will be forced
 to provide statically linked binaries. Static binaries  are bad because they
@@ -33,5 +33,5 @@
 
 
-<h2>The dos and don'ts</h2>
+<h2>The do's and don'ts</h2>
 
 You can ...
@@ -151,5 +151,5 @@
 C++ GUI libraries to maintain binary compatibility even between bigger
 release. The technique was quickly adapted as general programming
-pattern for the KDE libraries by everone who saw it. It's a great
+pattern for the KDE libraries by everyone who saw it. It's a great
 trick to be able to add new private data members to a class without
 breaking binary compatibiliy.
@@ -269,5 +269,5 @@
         delete_d(this);
 </pre></td></tr></table>
-That's not really required, but safes some resources.
+That's not really required, but saves some resources.
 
 <li> Do not forget to add a BCI remark, so that the hack can be


[prev in list] [next in list] [prev in thread] [next in thread]