? readmes.patch ? apps/entrance/data/themes/default/img/com.bat ? libs/etox/data/images/.new.bg.png Index: apps/ebindings/README =================================================================== RCS file: /cvsroot/enlightenment/e17/apps/ebindings/README,v retrieving revision 1.1 diff -c -u -r1.1 README --- apps/ebindings/README 19 Oct 2001 20:53:02 -0000 1.1 +++ apps/ebindings/README 15 May 2004 10:59:32 -0000 @@ -10,4 +10,4 @@ cd src/ ./ebindings -Please report any bugs with this app(backtraces are nice) to atmos@atmos.org +Please report any bugs with this app (backtraces are nice) to atmos@atmos.org Index: apps/entice/README =================================================================== RCS file: /cvsroot/enlightenment/e17/apps/entice/README,v retrieving revision 1.9 diff -c -u -r1.9 README --- apps/entice/README 16 Jan 2004 03:19:33 -0000 1.9 +++ apps/entice/README 15 May 2004 10:59:33 -0000 @@ -4,7 +4,7 @@ Simple installation insturctions in INSTALL -Entice currently takes no commandline options. It takes as arguments a +Entice currently takes no command line options. It takes as arguments a list of images to load. Run with no arguments it tries to load all files from the working directory (currently it even tries files that aren't images). You can instead give a directory name as a single argument, and Index: apps/entrance/data/themes/Nebulous/images/Nebulous_preview.png =================================================================== RCS file: /cvsroot/enlightenment/e17/apps/entrance/data/themes/Nebulous/images/Nebulous_preview.png,v retrieving revision 1.1 diff -c -u -r1.1 Nebulous_preview.png Binary files /tmp/cvswKJUDn and Nebulous_preview.png differ Index: apps/euphoria/README =================================================================== RCS file: /cvsroot/enlightenment/e17/apps/euphoria/README,v retrieving revision 1.4 diff -c -u -r1.4 README --- apps/euphoria/README 25 Mar 2004 20:39:29 -0000 1.4 +++ apps/euphoria/README 15 May 2004 10:59:37 -0000 @@ -60,7 +60,7 @@ Note that Euphoria will not function if it is not installed. -At this point your ready to rock. Start Euphoria but make sure +At this point you're ready to rock. Start Euphoria but make sure the XMMS2 Daemon is running (start via: "xmms2d"). You may want to install the Euphoria config database by following the instructions in the following section (there is a sample/default euphoria.db in the etc/ Index: apps/imlib2_tools/README =================================================================== RCS file: /cvsroot/enlightenment/e17/apps/imlib2_tools/README,v retrieving revision 1.1 diff -c -u -r1.1 README --- apps/imlib2_tools/README 5 Nov 2001 12:33:02 -0000 1.1 +++ apps/imlib2_tools/README 15 May 2004 10:59:47 -0000 @@ -1,6 +1,6 @@ TODO imlib2_tools -Clone of ImageMagick command line progtammes using Imlib2. +Clone of ImageMagick command line programs using Imlib2. Copyright (C) 2001 Horms ---------------------------------------------------------------------- Index: libs/ecore/README =================================================================== RCS file: /cvsroot/enlightenment/e17/libs/ecore/README,v retrieving revision 1.10 diff -c -u -r1.10 README --- libs/ecore/README 16 Apr 2004 01:46:54 -0000 1.10 +++ libs/ecore/README 15 May 2004 10:59:47 -0000 @@ -3,7 +3,7 @@ ------------------------------------------------------------------------------- Fast: -How ot build and install Ecore from this tarball? +How to build and install Ecore from this tarball? ./configure make su @@ -22,4 +22,4 @@ If you want to help with E... here's some ideas for ecore: * All of NETWM supported in ecore_x -* Support DBUS ontop of ecore_con (and modify to allow explicit paths) +* Support DBUS on top of ecore_con (and modify to allow explicit paths) Index: libs/edb/README =================================================================== RCS file: /cvsroot/enlightenment/e17/libs/edb/README,v retrieving revision 1.5 diff -c -u -r1.5 README --- libs/edb/README 15 Apr 2004 07:58:29 -0000 1.5 +++ libs/edb/README 15 May 2004 10:59:47 -0000 @@ -6,7 +6,7 @@ http://www.sleepycat.com (see src/LICENSE for license details). It is intended to make accessing database information portable, easy, fast and efficient as well as bypass the proplem of libdb continuously changing -formats. Read the Edb.h header for inormation on how to use the calls and the +formats. Read the Edb.h header for information on how to use the calls and the test directory for sample code. COMPILING and INSTALLING: Index: libs/embryo/README =================================================================== RCS file: /cvsroot/enlightenment/e17/libs/embryo/README,v retrieving revision 1.5 diff -c -u -r1.5 README --- libs/embryo/README 15 May 2004 05:04:07 -0000 1.5 +++ libs/embryo/README 15 May 2004 10:59:47 -0000 @@ -39,7 +39,7 @@ gcc Linux (PPC) gcc MacOS X (PPC) -And will likely work on more combinations. IT currently has problems on 64bit +And will likely work on more combinations. It currently has problems on 64bit SPARC CPUs. Other 64bit systems are untested. It is the aim to fix the code so it works on all commonly used architectures (32, 64bit, big and little endian, alignment forgiving/unforgiving). So far 64bit support is the major Index: libs/epeg/README =================================================================== RCS file: /cvsroot/enlightenment/e17/libs/epeg/README,v retrieving revision 1.2 diff -c -u -r1.2 README --- libs/epeg/README 20 Jan 2004 00:53:41 -0000 1.2 +++ libs/epeg/README 15 May 2004 10:59:47 -0000 @@ -6,7 +6,7 @@ Why write this? It's a convenience library API to using libjpeg to load JPEG images destined to be turned into thumbnails of the original, saving -information with these thumbnails, retreiving it and managing to load the image +information with these thumbnails, retrieving it and managing to load the image ready for scaling with the minimum of fuss and CPU overhead. This means it's insanely fast at loading large JPEG images and scaling them Index: libs/epsilon/README =================================================================== RCS file: /cvsroot/enlightenment/e17/libs/epsilon/README,v retrieving revision 1.1 diff -c -u -r1.1 README --- libs/epsilon/README 10 Dec 2003 05:43:07 -0000 1.1 +++ libs/epsilon/README 15 May 2004 10:59:47 -0000 @@ -39,7 +39,7 @@ ############################################################################ Build Instructions: -1. You need epeg(optional) from cvs, imlib2 and libpng +1. You need epeg (optional) from cvs, imlib2 and libpng 2. To compile and test epsilon it's your standard $ ./autogen.sh $ make Index: libs/evas/README =================================================================== RCS file: /cvsroot/enlightenment/e17/libs/evas/README,v retrieving revision 1.47 diff -c -u -r1.47 README --- libs/evas/README 8 Mar 2004 02:42:08 -0000 1.47 +++ libs/evas/README 15 May 2004 10:59:49 -0000 @@ -91,7 +91,7 @@ this is the nicest looking scaler that is not that much slower than tri-linear, but it looks really good. it also uses mipmaps and is optimised heavily. it is recommended to always use this unless you are really -struggling for speed and are qilling to forego the quality +struggling for speed and are willing to forego the quality DITHERING: --enable-small-dither-mask @@ -110,18 +110,18 @@ this enables the software x11 rendering engine that renders to X drawable targets using highly optimised software routines. there is no hardware assist here. this engine requires X11 to be installed to build (and run). -This si a godo generic engine that is fast and can run in X for good +This is a good generic engine that is fast and can run in X for good development and debugging purposes. --enable-fb -this is the software framebuffer drivign engine. this uses the linxu +this is the software framebuffer driving engine. it uses the linux framebuffer device (/dev/fb) and will currently just inherit the current framebuffer settings on the fb device and use them to run in. this engine is almost fully functional except for the fb management itself. i'd be quite happy for people to help out with fixing up the fb init & management code to properly set up a vt and release it etc. this engine is specifically geared -towards peoel writing minimalist display systems for embedded devices such +towards people writing minimalist display systems for embedded devices such as the ipaq, zaurus, etc. it also scales up to high-res desktop systems as well and performs outstandingly. i have measured up to 67% speedup over X11 using the fb driver insetad of X11. @@ -138,36 +138,36 @@ CPU: --enable-cpu-c -this enabled the c code. you can actually build the code withotu the c +this enabled the c code. you can actually build the code without the c fallback code and only have the mmx routines for example. it is suggested to -always use this regardless uness you have some definite size issues with the +always use this regardless unless you have some definite size issues with the code. --enable-cpu-mmx this enables the mmx optimised routines. this works for penitum, pentium2, pentium3, pentium4, athlon and duron processors. it can get quite -considerable speedups, souse it if you can. ppc owners just have to live with +considerable speedups, so use it if you can. ppc owners just have to live with the c fallback functions unfortunately as no one has provided any ALTIVEC asm routines yet. :) arm owners will also have to rely on the c fallback routines as i haven't managed to come up with any arm assembly that actually -can beat the c code (when compiled whht all optimisations) in speed. +can beat the c code (when compiled with all optimisations) in speed. --enable-cpu-sse -this enables sse optimisations availbale in he pentium3 and 4 cpus (not -athlon and duron or pentium 2 or pentium cpu's). ppc owners just have to +this enables sse optimisations available in the pentium3 and 4 cpus (not +athlon and duron or pentium 2 or pentium cpus). ppc owners just have to live with the c fallback functions unfortunately as no one has provided any ALTIVEC asm routines yet. :) arm owners will also have to rely on the c fallback routines as i haven't managed to come up with any arm assembly that -actually can beat the c code (when compiled whht all optimisations) in speed. +actually can beat the c code (when compiled with all optimisations) in speed. IMAGE LOADERS: --enable-image-loader-png this enables the loader code that loads png files using libpng. there may be call for embedded devices later that have custom written small image -loaders that use sless disk space than libpng to load custom format images. +loaders that use less disk space than libpng to load custom format images. for now this is the only loader so you may as well include it. --enable-image-loader-jpeg @@ -182,7 +182,7 @@ --enable-convert-16-rgb-555 -this is a converter for what many peoel knwo as "15 bit" color. you might +this is a converter for what many people know as "15 bit" color. you might want to enable this for X output as it used to be common to find many cards that do this. @@ -199,26 +199,26 @@ bits of each color component (red green and blue) are significant and work, so effectively the display is 12 bits of color, not 16, but padded out to fill 16bits, with unused bits in the color masks. X on the ipaq advertises -it as a full 16bpp 565 display (i can't remember what the linxu framebuffer -advertised it as) and so many lumsp fo code can be fooled into rendering -data badly because they think the output will look as the expect. thsi -renderer assuems the upper 4 bits fo each color primitie only are +it as a full 16bpp 565 display (i can't remember what the linux framebuffer +advertised it as) and so many lumps of code can be fooled into rendering +data badly because they think the output will look as they expect. this +renderer assuems the upper 4 bits of each color primitive only are significant and renders accordingly. this produces nice quality images on the ipaq and even still works in 16bpp 565 on your pc. it is highly -recommended to use thsi renderer if your target is an ipaq or your device -dislpays similar qualities of the ipaq for display purposes. +recommended to use this renderer if your target is an ipaq or your device +displays similar qualities of the ipaq for display purposes. --enable-convert-16-rgb-rot-0 this enables the 16bpp converters to run with 0 degrees rotation - this is -normal disp;ay and you shoudl really include this (though it is optional if you +normal display and you should really include this (though it is optional if you only ever want to do portrait mode - perhaps like on an ipaq embedded device) --enable-convert-16-rgb-rot-270 this enables the portrait mode (270 degree rotation) converteres for 16bpp. this is the standard display mode for things like pocketpc on the ipaq and -the zaurus etc. thsi si a optimised part of the rendering pipeline to allow +the zaurus etc. this is an optimised part of the rendering pipeline to allow portrait display with a much lower overhead than doing it through X. --enable-convert-24-rgb-888