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

List:       kde-commits
Subject:    developer.kde.org/documentation/standards/kde
From:       Brad Hards <bradh () frogmouth ! net>
Date:       2004-12-11 6:51:41
Message-ID: 20041211065141.3CE211B47F () office ! kde ! org
[Download RAW message or body]

CVS commit by bhards: 

Typo fixes


  M +15 -15    kde-style.html   1.3


--- developer.kde.org/documentation/standards/kde/kde-style.html  #1.2:1.3
@@ -50,5 +50,5 @@
 good one is for your intended users to try it, fortunately this is
 easy in an open development model such as ours. It is essential that
-developers are aware of how the user peceives their application and
+developers are aware of how the user perceives their application and
 that they are responsive to user feedback.
 </P>
@@ -78,5 +78,5 @@
 
 <LI><B>Don't overload windows with functionality or information that
-is irrelevent to the task in hand.</B>
+is irrelevant to the task in hand.</B>
 
 <LI><B>If you use a standard term such as 'Cancel' then you must use
@@ -87,5 +87,5 @@
 
 <LI><B>Don't keep secrets from the user.</B><BR>
-This includes making sure the user can get all information relevent to
+This includes making sure the user can get all information relevant to
 the task, and also things such as keyboard accelerators which should
 be documented.
@@ -93,9 +93,9 @@
 <LI><B>Always let the user see at a glance what is expected of
 them.</B><BR>
-Making sure that command functions are seperated from data entry
+Making sure that command functions are separated from data entry
 areas, and grouping and labeling widgets correctly can help ensure this.
 
-<LI><B>Group things that perform simmilar operations together, not
-things which are implemented in simmilar ways.</B><BR>
+<LI><B>Group things that perform similar operations together, not
+things which are implemented in similar ways.</B><BR>
 Think <I>user</I> interface.
 
@@ -108,5 +108,5 @@
 be performed at a given time.</B>
 
-<LI><B>Organise the intformation your give the user, the more
+<LI><B>Organise the information your give the user, the more
 structured it is the faster they can understand and navigate it.</B>
 </UL>
@@ -142,6 +142,6 @@
 
 <P>
-Applications are free to add other menu items and seperators between the
-<EM>Contents</EM> item and the seperator.
+Applications are free to add other menu items and separators between the
+<EM>Contents</EM> item and the separator.
 The actions that should be performed in response to each of these menu
 items is as follows:
@@ -164,5 +164,5 @@
 <A NAME="dialogs"><H3>Guidelines for dialogs</H3></A>
 <P>
-Note that occaisionaly dialogs can implemented as seperate binaries,
+Note that occasionally dialogs can implemented as separate binaries,
 this does not change the fact that as far as the user is concerned the
 window is a dialog and should act as such. An example of such a dialog
@@ -173,10 +173,10 @@
 
 <LI><B>The default action for a dialog should always be the least
-destuctive, this is normally 'Cancel'.</B>
+destructive, this is normally 'Cancel'.</B>
 
 <LI><B>Tabbed dialogs are useful, but can be very confusing to
 users.</B><BR>
 You should never use more than two rows of tabs and should think
-carefuly about your design if you need more than one, you would
+carefully about your design if you need more than one, you would
 probably be better off breaking your dialog into two or more smaller ones.
 
@@ -208,5 +208,5 @@
 <LI><B>If you change a controls behaviour you should reflect this
 change in it's appearance.</B><BR>
-For example a button that displays a menu should indictate this with
+For example a button that displays a menu should indicate this with
 an arrow (see KPanel for an example).
 
@@ -216,5 +216,5 @@
 significant benefits for your application.
 
-<LI><B>When writing new controls try to make them resonably
+<LI><B>When writing new controls try to make them reasonably
 general.</B><BR>
 If you write controls that other people can use then not only are you
@@ -232,5 +232,5 @@
 for translation.</B><BR>
 This is very easy to achieve, for example to allow
-translation of a label that says 'Hello' in english you simply call
+translation of a label that says 'Hello' in English you simply call
 <PRE>   klocale->translate("Hello");</PRE>
 Instead of using the string directly. You do not need to provide any


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