lostwages/wwn wn20070216_321.xml

Jeremy Newman jnewman at wine.codeweavers.com
Mon Sep 10 12:19:20 CDT 2007


ChangeSet ID:	31369
CVSROOT:	/opt/cvs-commit
Module name:	lostwages
Changes by:	jnewman at winehq.org	2007/09/10 12:19:20

Modified files:
	wwn            : wn20070216_321.xml 

Log message:
	Francois Gouget <fgouget at free.fr>
	WWN 321 spelling fixes

Patch: http://cvs.winehq.org/patch.py?id=31369

Old revision  New revision  Changes     Path
 1.2           1.3           +18 -18     lostwages/wwn/wn20070216_321.xml

Index: lostwages/wwn/wn20070216_321.xml
diff -u -p lostwages/wwn/wn20070216_321.xml:1.2 lostwages/wwn/wn20070216_321.xml:1.3
--- lostwages/wwn/wn20070216_321.xml:1.2	10 Sep 2007 17:19:20 -0000
+++ lostwages/wwn/wn20070216_321.xml	10 Sep 2007 17:19:20 -0000
@@ -76,7 +76,7 @@ still need some assistance with some iss
 <ol>
 <li> I need people to test this on any window manager they can to see if
 the results that I get can be reproduced, especially on older GNOME
-versions (I tested on GNOME 2.14) I was able to run a small test app
+versions (I tested on GNOME 2.14). I was able to run a small test app
 that I made over 120 times, and each time it docked perfectly, no zombie
 systray adapter windows like before.</li>
 
@@ -197,7 +197,7 @@ reports again.
 </p></quote>
 
 <p>[<i>Feb. 16 2007, ed. note: scans of the Wine codebase have been
-occuring regularly and work has been done to fix the bugs</i>]</p>
+occurring regularly and work has been done to fix the bugs</i>]</p>
 
 </section>
 <section
@@ -345,7 +345,7 @@ separately, which we should do to keep p
 Let me illustrate my idea:
 <ul>
 <li> Move out the GL calls from Set*State. Set*State writes the values to the 
-update stateblock and updates the refcounts(maybe we should kick internal 
+update stateblock and updates the refcounts (maybe we should kick internal 
 refcounting from wined3d altogether)</li>
 
 <li> Keep the stateblock and update stateblock structure as they are now. I think 
@@ -391,12 +391,12 @@ Thanks for all your work on audio!!
 
 <p>Eric Pouech thought there might be a problem with an ASIO driver:</p>
 <quote who="Eric Pouech"><p>
-I'm afraid submission (or integration in the Wine tree) will be problematic
-ASIO interface is copyrighted, and you need to sign an agreement to 
+I'm afraid submission (or integration in the Wine tree) will be problematic.
+The ASIO interface is copyrighted, and you need to sign an agreement to 
 Steinberg for using the API.
 IANAL, but including derivative work of a copyrighted API will not be 
 possible.
-But, this doesn't prevent from creating a standalone audio driver.
+But, this doesn't prevent you from creating a standalone audio driver.
 </p></quote>
 </section>
 <section
@@ -490,10 +490,10 @@ the .desktop files in ~/.wine). If anyon
 to know how it works.</p><p>
   There is a small problem that KDE scans the ~/.kde/applnk directory 
 (unlike Gnome that scans only the global directories /usr/share/applnk 
-and /etc/X11/applnk and that why the menu is not visible) and after this 
+and /etc/X11/applnk and that's why the menu is not visible) and after this 
 change will display the menu items twice. This can be fixed by creating 
 the ".desktop" in legacy directories with "OnlyShowIn=Old;".
-</p><p>  If this sound good I can send patches to winecreateprefix and 
+</p><p>  If this sounds good I can send patches to winecreateprefix and 
 wineshelllink with these fixes.
 </p></quote>
 
@@ -510,7 +510,7 @@ created there will be automatically remo
 When the $WINEPREFIX/menu directory is present a desktop item is created 
 there. The desktop item in legacy directories are created with 
 "ShowOnlyIn=Old;" so there will be no duplication of icons. If 
-$WINEPREFIX/menu is not present (i.e. a wineprefix create with an old 
+$WINEPREFIX/menu is not present (i.e. a wineprefix created with an old 
 wineprefixcreate) the files are created as they used to be (without 
 "ShowOnlyIn=Old;").</p></quote>
 
@@ -583,8 +583,8 @@ For this reason, using HeapAlloc(GetProc
 kernel32.dll is a possible way to go for "localspl.dll".
 
 </li><li>
-To let printing in Wine work as similar as possible as printing is done
-in Windows, (but without RPC and without the spooler service) we can
+To let printing in Wine work as similarly as possible as printing is done
+in Windows (but without RPC and without the spooler service), we can
 change the code path to 
 "winspool.drv -&gt; spoolss.dll -&gt; localspl.dll -&gt; CUPS/LPR"
 and use the exports from spoolss.dll.
@@ -620,14 +620,14 @@ usually garners some comments as well.)<
 <p>We used to have pretty good notes on regression testing, but
 things have changed now that we have git.  The general idea remains
 the same, but the mechanics are a bit different.  If you find a 
-regressions between releases, just bisect the release and see
+regression between releases, just bisect the release and see
 if the regression exists there, bisect that, and so on till you
 find the issue.  Of course, you can usually do a better job than
 that if you're tracking changes specific to a DLL.  Anyway, 
 Kapila De Silva asked:</p>
 <quote who="Kapila De Silva"><p>
-Im trying to track down an issue that occurred between 0.9.19 and
-0.9.20, and am using git bisect to track the issue. In the process of
+I'm trying to track down an issue that occurred between 0.9.19 and
+0.9.20, and I am using git bisect to track the issue. In the process of
 trying to identify the cause of the issue, I would like to be able to
 get the code up till a certain patch, and then apply patches one by one
 as well. 
@@ -641,7 +641,7 @@ searches and man pages. Can anyone give 
 What I do is to follow along with things on the shortlog:
 <ul><a href="http://source.winehq.org/git/?p=wine.git;a=shortlog">http://source.winehq.org/git/?p=wine.git;a=shortlog</a></ul>
 </p><p>
-Lets say you want to move your current branch to my recent patch
+Let's say you want to move your current branch to my recent patch
 "riched20: Rewrite of scrolling and some redrawing code." - you'd
 click the link "commit" to the right of it. In the page that you'll be
 taken to, you'll see a line like this:
@@ -652,10 +652,10 @@ you can then do a:
 </p><p>
 and your git will be moved to the point in time right after that
 commit. If you then want to manually apply a patch, click "commitdiff"
-to the right of it's entry in the shortlog, followed by "plain" on the
+to the right of its entry in the shortlog, followed by "plain" on the
 top - this will take you to a plaintext diff of the patch, which you
 could save to a file and apply with the patch command. ("patch -p1 &lt;
-thepatch.diff" usualy works well for me)</p></quote>
+thepatch.diff" usually works well for me)</p></quote>
 
 <p>Mike McCormack followed up on the last paragraph to mention two different
 ways that could be managed with git:</p>
@@ -710,7 +710,7 @@ My one win app that makes me a devotee o
 <a href="http://www.tabledit.com/download/tabled32.exe">www.tabledit.com/download/tabled32.exe</a>)
 has a custom font , tef260.ttf, that has failed to display since
 somewhere after ver 9.6. The program installs the font into 
-c:\windows\font, but can not display it within the program, instead
+c:\windows\font, but cannot display it within the program, instead
 displaying for the most part, empty squares. 
 </p><p>
 I tried putting/removing tef260.ttf into /usr/local/share/wine/fonts,



More information about the wine-cvs mailing list