Enlightenment CVS committal
Author : technikolor
Project : e17
Module : docs
Dir : e17/docs/edjebook/xml
Modified Files:
bookinfo.xml edc_ref.xml edc_tour.xml edje_api.xml
guidelines.xml overview.xml positioning.xml preview.xml
programs.xml
Log Message:
Commiting a patch sent in by dan sinclair <[EMAIL PROTECTED]>.
Many thanx Dan.
===================================================================
RCS file: /cvsroot/enlightenment/e17/docs/edjebook/xml/bookinfo.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -3 -r1.1 -r1.2
--- bookinfo.xml 20 Feb 2004 08:22:10 -0000 1.1
+++ bookinfo.xml 1 Apr 2004 09:58:59 -0000 1.2
@@ -40,8 +40,8 @@
<abstract>
<para>
A complete guide to designing interfaces using Edje and utilizing them
- effectively in your EVAS applications. Includes complete overview of Edje
- Data Collections (EDC) and Edje API, including sample code and reference
+ effectively in your EVAS applications. Includes a complete overview of Edje
+ Data Collections (EDC) and the Edje API, including sample code and reference
material. Utilizing Edje effectively can simplify and streamline application
development and make nearly any application completely skinable by even
non-programmers.
</para>
===================================================================
RCS file: /cvsroot/enlightenment/e17/docs/edjebook/xml/edc_ref.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -3 -r1.4 -r1.5
--- edc_ref.xml 8 Mar 2004 20:16:43 -0000 1.4
+++ edc_ref.xml 1 Apr 2004 09:58:59 -0000 1.5
@@ -64,7 +64,7 @@
<entry>images</entry>
<entry>image,</entry>
<entry>"image" STORAGE_METHOD;</entry>
- <entry>Where storage method is of the following: COMP for lossless compressed, RAW
for lossless uncompressed, or LOSSY for lossy compressed follorwed by
+ <entry>Where storage method is of the following: COMP for lossless compressed, RAW
for lossless uncompressed, or LOSSY for lossy compressed followed by
the quality level (0-100)
ex: image, "button.png" LOSSY 85;
ex: image, "backdrop.jpg" RAW;</entry>
@@ -74,7 +74,7 @@
<entry>group</entry>
<entry>name,</entry>
<entry>"group_name";</entry>
- <entry>Name used to access individual interface in an EET</entry>
+ <entry>Name used to access an individual interface in an EET.</entry>
</row>
<row>
@@ -107,7 +107,7 @@
</entry>
<entry>"part_name";
</entry>
- <entry>Symbolic part name, used for later reference in EDC
+ <entry>Symbolic part name, used for later reference in EDC.
</entry>
</row>
@@ -118,7 +118,7 @@
</entry>
<entry>TYPE;
</entry>
- <entry>Where type is: IMAGE, RECT, TEXT or NONE. If no type is specified IMAGE is
the default type.
+ <entry>Where type is: IMAGE, RECT, TEXT or NONE. Defaults to IMAGE if no type is
specified.
</entry>
</row>
@@ -152,9 +152,8 @@
</entry>
<entry>0;
</entry>
- <entry>Boolean value specifying whether a part repeats an event to the part below
it. When repeat is set to 0 (off, the default) and two parts that acc
-ept events
- are on top of each other the top most object will recieve the event and not
any parts below it, turning repeat to 1 (on) will continue to send the
+ <entry>Boolean value specifying whether a part repeats an event to the part below
it. When repeat is set to 0 (off, the default) and two parts that accept events
+ are on top of each other the top most object will receive the event and not
the parts below it, turning repeat to 1 (on) will continue to send the
event down to
the next part below it.
</entry>
@@ -168,8 +167,7 @@
</entry>
<entry>"part";
</entry>
- <entry>Clip to the size of the specified part. Any amount of the current part that
exends beyond the size of the clipped to part will be clipped off. C
-lipped text parts
+ <entry>Clip to the size of the specified part. Any amount of the current part that
extends beyond the size of the clipped to part will be clipped off. Clipped text parts
always truncate the text string to "...".
</entry>
</row>
@@ -203,8 +201,7 @@
</entry>
<entry>"name" INDEX;
</entry>
- <entry>Descriptive name for the individual state, the default state must always be
named "default". The INDEX value is a double between 0.0 and 1.0 whic
-h indicates levels of completion, that defaults to 0.0. Multiple states can have the
same name yet with a different index value.
+ <entry>Descriptive name for the individual state, the default state must always be
named "default". The INDEX value is a double between 0.0 and 1.0 which indicates
levels of completion, the default is 0.0. Multiple states can have the same name yet
with a different index value.
ex: state, "default" 0.0;
</entry>
</row>
@@ -227,7 +224,7 @@
</entry>
<entry>HOR_VAL VER_VAL;
</entry>
- <entry>Specify alignment of the part within it's container as specified by
rel1/rel2. Values are specified as doubles from 0.0 (align left/top) to 1.0 (
+ <entry>Specify alignment of the part within its container as specified by
rel1/rel2. Values are specified as doubles from 0.0 (align left/top) to 1.0 (
align right/bottom).
ex: align, 0.5 0.5; (Aligns part in center of container)
ex: align, 0.0 1.0; (Aligns part to bottom left of container)
@@ -266,7 +263,7 @@
<entry>HOR_VAL VERT_VAL;
</entry>
<entry>Integer stepping values in integer pixels for horizontal (arg1) and vertical
(arg2) scaling. When stepping is enabled the width or/and height of
-the image will always be divisable by it's stepping value when scaled. Default
stepping values are 0 0 (ie: stepping disabled).
+the image will always be divisable by its stepping value when scaled. Default
stepping values are 0 0 (ie: stepping disabled).
ex: step, 20 1 (Image width must always be multple of 20, ie: 0, 20, 40, 60, etc.
Height can be any value)
</entry>
</row>
@@ -278,8 +275,7 @@
</entry>
<entry>MIN MAX;
</entry>
- <entry>Double min (arg1) and max (arg2) aspect ratio values. This controls the
aspect ratio (ratio of width to height) of a scaled part, typically image
-s. The default ratio is 0.0. If both values are the same the ratio is fixed.
+ <entry>Double min (arg1) and max (arg2) aspect ratio values. This controls the
aspect ratio (ratio of width to height) of a scaled part, typically images. The
default ratio is 0.0. If both values are the same the ratio is fixed.
ex: aspect, 1.0 5.0; (Minimum aspect of 1:1, maximum of 5:1 - Width:Height);
</entry>
</row>
@@ -291,8 +287,7 @@
</entry>
<entry>LEFT RIGHT TOP BOTTOM;
</entry>
- <entry>Border scaling values for an image part as specified in integer pixel
widths, for each four sides of an image. This will stop Edje from scaling t
-he outside edge of an image when scaling an image part.
+ <entry>Border scaling values for an image part as specified in integer pixel
widths, for each four sides of an image. This will stop Edje from scaling the outside
edge of an image when scaling an image part.
ex: border, 10 10 10 10; (Scale the edge of the image part 10 pixels on all sides)
</entry>
</row>
@@ -340,8 +335,7 @@
</entry>
<entry>HOR_VAL VERT_VAL;
</entry>
- <entry>Doubles representing the horizontal (arg1) and vertical (arg2) positioning
of top left corner (for rel1) or bottom right corner (for rel2) as rel
-ative to the part specified by the "to" keyword. If no "to" keyword is present, the
values are relative to the corners of the interface.
+ <entry>Doubles representing the horizontal (arg1) and vertical (arg2) positioning
of top left corner (for rel1) or bottom right corner (for rel2) as relative to the
part specified by the "to" keyword. If no "to" keyword is present, the values are
relative to the corners of the interface.
ex: relative, 0.0 1.0; (For rel1 with no "to": top left corner of part is positioned
at the left (0.0), bottom (1.0) corner of the interface.)
</entry>
</row>
@@ -353,7 +347,7 @@
</entry>
<entry>HORZ_OFF VERT_OFF;
</entry>
- <entry>Integers specifying deviation in pixels from the position as defined by the
relative keyword, both horizontally (arg1) and vertically (arg2)
+ <entry>Integers specifying deviation in pixels from the position as defined by the
relative keyword, both horizontally (arg1) and vertically (arg2).
ex: offset, 5 10; (Position 5 px to the right and 10 px down from the position as
stated by the relative keyword)
</entry>
</row>
@@ -377,8 +371,7 @@
</entry>
<entry>"part_name";
</entry>
- <entry>Specify another part as the reference to be used for the positioning of the
current part. Same as "to", but relativity applies only on the X axis
-.
+ <entry>Specify another part as the reference to be used for the positioning of the
current part. Same as "to", but relativity applies only on the X axis.
</entry>
</row>
@@ -389,8 +382,7 @@
</entry>
<entry>"part_name";
</entry>
- <entry>Specify another part as the reference to be used for the positioning of the
current part. Same as "to", but relativity applies only on the Y axi
-s.
+ <entry>Specify another part as the reference to be used for the positioning of the
current part. Same as "to", but relativity applies only on the Y axis.
</entry>
</row>
@@ -413,8 +405,7 @@
</entry>
<entry>"image_name";
</entry>
- <entry>Name of an image to be used in an animation loop. Images are dispay in the
order they are listed. There is no limit to the number of tweens tha
-t can be specified.
+ <entry>Name of an image to be used in an animation loop. Images are dispay in the
order they are listed. There is no limit to the number of tweens that can be
specified.
</entry>
</row>
@@ -438,8 +429,7 @@
</entry>
<entry>Doubles representing the horizontal (arg1) and vertical (arg2) position from
which a fill (tile) should start within it's container as defined by
rel1/rel2. Tiling
- then occurs in all directions from that point of origin. This is similar in
use to relativity by rel1 except that it is relative to the parts con
-tainer rather than
+ then occurs in all directions from that point of origin. This is similar in
use to relativity by rel1 except that it is relative to the parts container rather than
the whole interface.
ex: relative, 0.5 0.5; (part starts tiling from the middle of it's container)
</entry>
@@ -465,8 +455,7 @@
</entry>
<entry>HOR_VAL VERT_VAL;
</entry>
- <entry>Doubles representing the horizontal (arg1) and vertical (arg2) position of
the bottom right corner of a fill (tile). This is similar in use to r
-elativity by rel2 except that it is relative to the parts container rather than the
whole interface.
+ <entry>Doubles representing the horizontal (arg1) and vertical (arg2) position of
the bottom right corner of a fill (tile). This is similar in use to relativity by
rel2 except that it is relative to the parts container rather than the whole interface.
ex: relative, 1.0 1.0; (Tile fills entire space)
</entry>
</row>
@@ -478,8 +467,7 @@
</entry>
<entry>HOR_VAL VERT_VAL;
</entry>
- <entry>Integers specifying a pixel offset horizontally (arg1) and vertically (arg2)
from the relative position specified by size{relative,}. This is si
-milar in use to offset
+ <entry>Integers specifying a pixel offset horizontally (arg1) and vertically (arg2)
from the relative position specified by size{relative,}. This is similar in use to
offset
used in rel2.
</entry>
</row>
@@ -502,7 +490,7 @@
</entry>
<entry>"font_name";
</entry>
- <entry>Font used for text, where "font_name" is the name of the font file minus its
extension. Path to font is determined by your applications
+ <entry>Font used for text, where "font_name" is the name of the font file minus its
extension. The path to the font is determined by your applications
evas font path. ex: font, "Impact"; (Font used is Impact.ttf found in the
evas font path)
</entry>
</row>
@@ -536,8 +524,7 @@
</entry>
<entry>HOR_VAL VERT_VAL;
</entry>
- <entry>Boolean values specifying whether the current text string should define the
minimum size of the part, such that all future changes to the text st
-ring can
+ <entry>Boolean values specifying whether the current text string should define the
minimum size of the part, such that all future changes to the text string can
be no smaller both horizontally (arg1) and vertically (arg2).
</entry>
</row>
@@ -549,7 +536,7 @@
</entry>
<entry>0.5 0.5;
</entry>
- <entry>Alignment of text within its containers as defined by rel1/rel2,
horizontally (arg1) and vertically (arg2).
+ <entry>Alignment of text within its containers is defined by rel1/rel2,
horizontally (arg1) and vertically (arg2).
</entry>
</row>
@@ -571,7 +558,7 @@
</entry>
<entry>SIGNAL;
</entry>
- <entry>Specifies signal(s) that a should cause program to run. The signal recieved
must match the specified source to run. Signals may be globbed, but
+ <entry>Specifies signal(s) that should cause the program to run. The signal
received must match the specified source to run. Signals may be globbed, but
only
one signal keyword per program may be used.
ex: signal, "mouse,clicked,*"; (clicking any mouse button that matches source
starts program)
@@ -608,8 +595,7 @@
</entry>
<entry>TYPE LENGTH;
</entry>
- <entry>Defines how transistions occur using STATE_SET action. Where type is the
style of the transistion and length is a double specifying the number o
-f
+ <entry>Defines how transistions occur using STATE_SET action. Where type is the
style of the transistion and length is a double specifying the number of
seconds in which to preform the transistion. Valid types are: LINEAR,
SINUSOIDAL, ACCELERATE, and DECELERATE
</entry>
</row>
@@ -621,8 +607,7 @@
</entry>
<entry>"action-target";
</entry>
- <entry>Program or part on which the specified action acts. Multiple target
keywords may be specified, one per target. SIGNAL_EMITs do not have targets
-.
+ <entry>Program or part on which the specified action acts. Multiple target
keywords may be specified, one per target. SIGNAL_EMITs do not have targets.
</entry>
</row>
@@ -633,7 +618,7 @@
</entry>
<entry>"next-program";
</entry>
- <entry>Specifies a program run after the current program completes.
The source and signal parameters of a program run as an "after" are ignored. Multiple
"after" statements can be specified per program.
+ <entry>Specifies a program to run after the current program completes.
The source and signal parameters of a program run as an "after" are ignored.
Multiple "after" statements can be specified per program.
</entry>
</row>
===================================================================
RCS file: /cvsroot/enlightenment/e17/docs/edjebook/xml/edc_tour.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -3 -r1.3 -r1.4
--- edc_tour.xml 8 Mar 2004 20:17:36 -0000 1.3
+++ edc_tour.xml 1 Apr 2004 09:58:59 -0000 1.4
@@ -8,10 +8,10 @@
be. When determining how to design your interface, it's common to use GIMP
as a layout tool, this is particularly helpful for designing your interface with
Edje as you can see exactly how each element is going to be positioned and relate
-to other parts of your interface, which is espcially helpful when learning Edje.
+to other parts of your interface, which is especially helpful when learning Edje.
Next, it's time to actually build your real interface. This starts by creating
a file typically labeled with a .edc extension. Once you've created your EDC,
-you will generate the EET that will be used by your application using edje_cc,
+you will generate the EET that will be used by your application. This is done using
<command>edje_cc</command>,
the Edje Collection Compiler. Edje_cc will pack your EDC plus all of the images
your interface will need into one tight compact EDC, and will even compress
images if you specified compression in your EDC. This generated EET will
@@ -24,7 +24,7 @@
</para>
<para>
-Before starting off with Edje on your own, you should look at the example in
+Before starting off with Edje on your own, you should look at the examples in
the Edje source tree. In the <filename class='directory'>edje/data</filename>
directory you will find a script named
<filename>e_logo.sh</filename>.
Run that script and an EET will be generated. The script simply runs
<command>edje_cc</command> with the appropriate
@@ -198,11 +198,11 @@
</para>
<para>
-The images section is the first section to examine. It simply contains a list of
images that we with to
+The images section is the first section to examine. It simply contains a list of
images that we wish to
include in our interface. Each image will have a line describing how to store it, in
the form: image, "filename" STORAGE_METHOD;.
The storage method is a description of how Edje should store the file in the
generated EET. Valid storage methods are COMP, RAW,
and LOSSY. RAW stores the image in raw format, note that this doesn't mean
unmodified format, a RAW stored PNG will
-be uncompressed and stored as the raw image, thus you tidy 1K PNG may be stode as an
8K raw image.
+be uncompressed and stored as the raw image, thus your tidy 1K PNG may be stode as an
8K raw image.
The COMP method will use lossless compression on your image. And the LOSSY method
will use a lossy compression on
your image. The LOSSY method is followed by an integer between 0 and 100, defining
the quality level.
</para>
@@ -213,7 +213,7 @@
applications interface or diffrent looks for your one interface, all in one EET for
easy distribution. Each group is given
a name, in this case "test". Any time you reference your EET you will specify both
the EET file name, and the group to use so
choose your name descriptively. The next two lines are the min and max size of our
interface in pixels. The arguments to
-min and max are horizontal size then the verital size. So our interface case a
minimum size of 32x32 and maximum of 1024x768.
+min and max are the horizontal size then the verital size. So our interface has a
minimum size of 32x32 and maximum of 1024x768.
</para>
<para>
@@ -229,24 +229,24 @@
A part will contain one or more description sections. Each description is a diffrent
state of our part. The descriptions
define how our part should look, what images or text the part uses, where it should
be positioned, how it should be tiled, etc.
In this case our background only needs one state, which we call default, using the
state keyword. The number following
-the state name defines an index value which is currently unused, simply use 0.0.
Next we see two sections define the
+the state name defines an index value which is currently unused, simply use 0.0.
Next we see two sections defining the
positioning of our part, rel1 and rel2. Each rel
section will contain the keywords relative and offset, and optionally to. If the to
keyword is omited then the position
is relative to the full size of the interface as described by min and max in the
group section. rel1 is the positioning of
the top left corner of the part and rel2 is the positioning of the bottom right
corner of the part. The relative keyword is followed by two doubles ranging from 0.0
to 1.0. As with min and max, the first
-value is the horizontal and the second is the vertical. The offset specified the
pixel deviation from the relative point.
+value is the horizontal and the second is the vertical. The offset specifies the
pixel deviation from the relative point.
In the case of our background, the top left (rel1) of our part (image) is relative to
the top left corner of the interface, with no
offset. The bottom right (rel2) of our part is relative to the bottom right of the
interface, offset by 1 pixel left and 1 pixel
-up. Therefore, this part fills the entire interface. More information about
positioning can before later in this guide. The last
+up. Therefore, this part fills the entire interface. More information about
positioning can be found later in this guide. The last
section in this parts description is the image section. This section describes which
images to use. One or more images
can be specified, the image that is first seen is denoted by the keyword normal.
More images can be added using the
-keyword "tween" to form animations, but we will discuse that more later.
+keyword "tween" to form animations, but we will discuss that in a later section.
</para>
<para>
While parts may seem confusing and complicated at first, hopefully you now can look
at the part we just reviewed and simply
-say that it's an image part named background that doesn't accept mouse events, fills
the interface completely using the
+say that it's an image part named background that doesn't accept mouse events, and
fills the interface completely using the
image background.png.
</para>
@@ -256,10 +256,10 @@
rectangle we will use as a button, or in otherwords, the unclicked state of our
button. The second state is the clicked
state. You'll notice that the default and clicked states look almost identical, the
only change is the color and name.
This means that when we change from state default to state clicked, the only thing
that changes is the color of the rectangle.
-States are changed using programs, which we will discuse later. You'll notice that
the descriptions contain min and max keywords,
+States are changed using programs, which we will discuss later. You'll notice that
the descriptions contain min and max keywords,
these are used to define the size of the part. If they are omited, like in the
background part, the part will fill the maximum
-ammount of avalible space (ie: the whole interface, as limited by rel1 and rel2).
The alignment keyword specifies alignment
-of our part within its avalible space (container). Values for align are again
horizontal alignment followed by verital alignment,
+amount of avalible space (ie: the whole interface, as limited by rel1 and rel2). The
alignment keyword specifies alignment
+of our part within its available space (container). Values for align are again
horizontal alignment followed by verital alignment,
using doubles. So in this case the rectangle will be an absolute 100x50 pixels, with
a container the size of the whole interface
(as defined by rel1/rel2), and is positioned in the middle of that container. No
matter how big or small the interface is the
100x50 pixel rectangle will always stay in exactly the middle of the screen and never
resize. The color keyword is applicable
@@ -274,12 +274,12 @@
the bottom right corner of the part by 1 pixel to the left and upwards from that
point. The text section describes the text
itself. The text keyword describes the text to display ("Press Me"), the font to use
("redensek"), the size of that font (14), and
the alignment of the text within the container as defined by rel1/rel2. The font
specified to be used must be added to
-your EVAS font path in your application, and the font name is the filename minus it's
extention (ie: .ttf).
+the EVAS font path in your application, and the font name is the filename minus it's
extention (ie: .ttf).
</para>
<para>
-A word about layering. There is not specific keyword for layering in EDCs on a
part-by-part basis. Each
-new part is layered on top of the previous. Therefore in our sample EDC the text is
rendered ontop of the button, which
+A word about layering. There is no specific keyword for layering in EDCs on a
part-by-part basis. Each
+new part is layered on top of the previous part. Therefore in our sample EDC the
text is rendered on top of the button, which
sits atop the background. If we had defined the button before the background it
would not have been visable. While
this is common sense for the mostpart, it can be a common cause of confusion when
modifying a large EDC if you aren't
careful. Whenever you modify or add parts to your EDCs check whats above and below
it.
@@ -289,27 +289,27 @@
The final section in our EDC is the programs section. Programs breath life into the
static parts that
make up our interface. Programs are largely based on the reception of signals.
Signals can be generated by user
interfaction, Edje itself, or an external force (usually your window manager). For
instance, a user generated signal would be
-mouse in (when the user moves their pointer over a part), or mouse down (user
depreses mouse button over a part).
+mouse in (when the user moves their pointer over a part), or mouse down (user
depresses a mouse button over a part).
An Edje generated signal would include a "load" signal (Edje loads the EET), or
"program,start" (when some other program starts running). An externally generated
signal would effect the entire Edje
interface, generally from a window manager, such as "move" (your interface window is
moved) or "show" (your interface is displayed).
</para>
<para>
-The first program in our example is to change the state of our button part when it is
clicked on. The program
-name is "button_click". The program is run when it recieves the signal
"mouse,down,1", meaning when the left mouse button is
+The first program in our example is to change the state of our button part when it is
clicked. The program
+name is "button_click". The program is run when it receives the signal
"mouse,down,1", meaning when the left mouse button is
depressed over your part that accepts mouse events the program activates. Signals
are globable, meaning if we
wanted the program to run when any mouse button is depressed on our part we could use
the signal "mouse,down,*", in fact
we could use the signal "*" meaning that ANY signal effecting the part would run the
program. The next keyword is source,
-which defines the part (or program) from which the signal will be recieved, in this
case button. Sources are also globable.
+which defines the part (or program) from which the signal will be received, in this
case button. Sources are also globable.
The next keyword is
-action, this what the program actually does. Actions can change part states, stop
the action of other programs, and emit
+action, this what the program actually does. Actions can change part states, stop
the action of other programs, or emit
signals. In this case the action STATE_SET still change state to "clicked". The
following double (0.0) is currently
-unused and should simply be set to 0.0. The target argument that follows is the part
or program on which the action acts
-apon. The final keyword, after, optionally defines another program to be run after
the current program completes.
+unused and should simply be set to 0.0. The target argument that follows is the part
or program on which the action acts.
+The final keyword, after, optionally defines another program to be run after the
current program completes.
When a signal is received all the programs which accept the incoming signal and match
the source will be run, and
in this way very often the keyword "after" is not required, however it can still be
used for some crafty purposes which we'll explore later.
-After's can also be used as a looping mechignism, by specifying the current program
to re-run after it completes, however it
+After's can also be used as a looping mechanism, by specifying the current program to
re-run after it completes, however it
should be noted that any signal specified for the program must be met on every run of
that program, even if it loops back
to itself.
</para>
@@ -318,7 +318,7 @@
Looking at the first program again, we can now clearly see that the program
"button_click" will be run when the left
mouse button is depressed on our "button" rectangle. It will change the state of the
target "button" to "clicked" (which will change the color
as noted earlier), and once it completes will run the "do_me" program. Thus, looking
at the next program "button_unclick" we can
-see that it will change the state of target "button" to the "default" state (back to
its origonal color) when the
+see that it will change the state of target "button" to the "default" state (back to
its original color) when the
left mouse button is released over the source part "button". Hence we have an
animated button! Typically images would be used instead
of simple rectangles, which would simply omit the color keyword and add an image
section to both states, one image for the default
state and one for the clicked state. Lastly we see that the after keyword is used to
run the program "stop_doing_me" after "button_unclick"
@@ -331,11 +331,11 @@
The third program as referenced by the "button_click" program. This program will
accept any signal (as denoted by a * for the
signal). The source is defined as a program in this case, rather than a part, so the
program will run when any signal is accepted
from the "button_click" program. The action defined is SIGNAL_EMIT, which will send
the specified signal, here "PANTS ON", which
-is typically used by your application code. The third argument of of action for
SIGNAL_EMIT is the source from which the signal came.
-In your application code this signal would be recieved by a callback handler, which
would call a specified function based on the recipt of
+is typically used by your application code. The third argument of the action for
SIGNAL_EMIT is the source from which the signal came.
+In your application code this signal would be received by a callback handler, which
would call a specified function based on the recipt of
a specified signal from a specific source. We'll learn more about these signals when
we discuse the Edje API later. The keyword
-"in" accepts two arguments, both doubles. "in" specifies a delay on running your
program, the first argument is the number of seconds
-to wait before running the program, and the second argument specifies a the maximum
random delay which is added to the first argument.
+"in" accepts two arguments, both doubles. The "in" keyword specifies a delay on
running your program, the first argument is the number of
+seconds to wait before running the program, and the second argument specifies the
maximum random delay which is added to the first argument.
This is useful when you want the program to wait for a random amount of time that is
at least a half a second but no more than 3 seconds,
which would be described as "in, 0.5 3.0;". Delays always occur before the action
specified by the program is preformed.
Our final keyword is after, which will run the program "do_me" after the current
program completes, which in this case is a loop.
@@ -352,9 +352,9 @@
<para>
You should now take the sample EDC above, and use Edje_CC to build an eet. You can
get the background image here: BACKGROUNDIMG.
Using the edje_cc build your EET like this: "edje_cc -v -id . sample.edc sample.eet",
putting the image in the same directory with the EDC.
-You should put the font "redensek.ttf" in a directory named "fonts/" where your EET
will be used with edje (the viewer) from.
+You should put the font "redensek.ttf" in a directory named "fonts/" where your EET
will be view with edje (the viewer).
You can then preview that EET with Edje, specifying the EET filename and the group
name: "edje sample.eet test". Play with the EDC
-alittle untill you think you are familar with the syntax, layout and basic
functionality of Edje EDCs.
+a little until you think you are familar with the syntax, layout and basic
functionality of Edje EDCs.
</para>
</section>
===================================================================
RCS file: /cvsroot/enlightenment/e17/docs/edjebook/xml/edje_api.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -3 -r1.1 -r1.2
--- edje_api.xml 20 Feb 2004 08:22:10 -0000 1.1
+++ edje_api.xml 1 Apr 2004 09:58:59 -0000 1.2
@@ -89,7 +89,7 @@
application needs to catch that signal and then do something with it, this
functionality is provided by Edje signal callbacks.
The Edje API provides you with two calls, one to add and one to delete signal
callbacks: edje_object_signal_callback_add() and
edje_object_signal_callback_del(). Both functions take 4 arguments: the Evas_Object
(your edje), the signal thats emited,
-the source of that emission, and the function that should be called when the signal
is recieved.
+the source of that emission, and the function that should be called when the signal
is received.
These functions will not allow you to pass NULL arguments, and therefore if you want
to create callbacks for several sources that
emit the same signal you will need to add a seperate callback for each of the
sources. The add function allows one more
argument, a void pointer to any data you want passed to the callback function.
===================================================================
RCS file: /cvsroot/enlightenment/e17/docs/edjebook/xml/guidelines.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -3 -r1.1 -r1.2
--- guidelines.xml 20 Feb 2004 08:22:10 -0000 1.1
+++ guidelines.xml 1 Apr 2004 09:58:59 -0000 1.2
@@ -3,7 +3,7 @@
<para>
The purpose of Edje is to abstract as completely as possible the design of the
interface from the application code. Always
-keep this in mind when using Edje. While at times Edje's API seems inadiquate or
frustrating in its lack of customization, it
+keep this in mind when using Edje. While at times Edje's API seems inadequate or
frustrating in its lack of customization, it
is this way for a reason: to keep you as a coder from taking power away from the
themer. If at any point the API seems like
a restriction realize that what you want to do is possible, but should be done in the
EDC not in the application code.
</para>
@@ -17,7 +17,7 @@
<title>Edje Spec Files</title>
<para>
-Once you have created you application and a default EDC you will want to make it as
easy as possible for other developers and
+Once you have created your application and a default EDC you will want to make it as
easy as possible for other developers and
themers to create new interfaces for you application. While developers can read your
code and figure out what does what, many
of the themers can not, therefore a standardized method of describing what the
application requires and provides should be utilized.
This is done by creating a flat text file named README.edje. Below is an example of
the format that should be used in your README.edje:
@@ -134,11 +134,11 @@
</figure>
<para>
-This scheme allows the themer to have an understanding of what functionality is
avalible and what
+This scheme allows the themer to have an understanding of what functionality is
available and what
parts will be accessed by the application code and therefore must exist, even if
hidden. A changelog
should be present to list the changes in the application that could effect themes
past and present.
A "Features and Notes" section is optional but allows a place to outline various
functionality of the application
-as well as notes from the coder to the themer as to now the app is intended to be
used, their wishes, etc.
+as well as notes from the coder to the themer as to how the app is intended to be
used, their wishes, etc.
This file should be present in the top level directory of your codebase.
</para>
@@ -161,13 +161,13 @@
<para>
An important consideration for themeing was how to deal with distribution of themes.
Due to the ugly nature of using
-renamed tarballs for data distribution Edb and then EET came to live. EET provides a
simplistic manner of distributing
-complete themes and interfaces in a convinient single file package. Because EET will
compress your images there is no need
+renamed tarballs for data distribution Edb and then EET came to life. EET provides a
simplistic manner of distributing
+complete themes and interfaces in a convenient single file package. Because EET will
compress your images there is no need
to re-compress an EET, though it is the distributers discretion to do so. When
hosting themes pre-compiled EETs should be provided.
-The images and source EDC does not, but it is recommended that you make it avalible
on request or in the same place as the EET
-using a simple and clear file convension such as: theme.eet and theme-src.tgz.
Providing the source gives back to the community
+The images and source EDC does not need to be provided, but it is recommended that
you make it avalible on request or in the same place
+as the EET using a simple and clear file convension such as: theme.eet and
theme-src.tgz. Providing the source gives back to the community
not only a nice theme but also a valuable learning tool for others. Themes should
<emphasis>not</emphasis> be distributed in
-tarballs as it defeats the purpose of single file, one step distribution.
+tarballs as it defeats the purpose of a single file, one step distribution.
</para>
</section>
===================================================================
RCS file: /cvsroot/enlightenment/e17/docs/edjebook/xml/overview.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -3 -r1.1 -r1.2
--- overview.xml 20 Feb 2004 08:22:10 -0000 1.1
+++ overview.xml 1 Apr 2004 09:58:59 -0000 1.2
@@ -12,7 +12,7 @@
These EET's are generated from an Edje EDC file in which diffrent parts of the
interface
are described and laid out, and how those parts interact with your application. This
allows for the interface to be completely changed simply by creating a new EDC and
-generating from it the EET that your application can use. In more popular terms, Edje
+generating the EET for your application to use. In more popular terms, Edje
makes every application that uses it "skinable". Raster describes Edje as "an attempt
to find a middleground between themeing and programming without turning the theme
itself into just yet another program".
@@ -26,7 +26,7 @@
<para>
The Edje EDC contains every detail about your interface. An EDC is
a simple text file that uses C like syntax. The file is broken into
-three distinct section: images, data, and collections. The image section contains
+three distinct sections: images, data, and collections. The image section contains
a list of all the images your interface will use. When you compile/generate your
EDC into an EET all the images specified will be loaded into the EET itself allowing
you
to distribute your interface (or skin if you prefer) as a single file. When
@@ -40,16 +40,16 @@
<para>
The collections in an EDC are comprised of one or more groups. Each group
contains parts and programs. A part is a single element of your interface, such
-as a text element, or a rectangle, or an image. Each part is thuroughly described
+as a text element, or a rectangle, or an image. Each part is throughly described
for one or more states. For instance, an image part might actually have two images
-in it, each in a diffrent state, one for a normal state and one for a clicked (mouse
down)
+in it, each in a different state, one for a normal state and one for a clicked (mouse
down)
state. A part may have as many states defined as you like.
</para>
<para>
These parts are then referenced in the programs. Programs are descriptions about
how the interface should respond to both the user and the application code itself. A
-program can accept interface event (such as mouse button 1 down), and then change the
state of
+program can accept interface events (such as mouse button 1 down), and then change
the state of
a part described earlier (change to state clicked) to create an effect. Programs
can also emit signals to your application. In your application code you would define
a callback for that event. Each program is concise and distinct. For example, to
@@ -60,10 +60,10 @@
<para>
Because of the abstraction Edje provides, your applcation only needs to
-know the name of the EET to use, what signals it will recieve from
-the interface so that callbacks can be defined when that event is recieved, and
+know the name of the EET to use, what signals it will receive from
+the interface so that callbacks can be defined when that event is received, and
what text parts in the interface can be modified. This allows maximum flexability in
-interface design, including the ability to offload interface to graphic designers and
+interface design, including the ability to offload the interface to graphic designers
and
themers freeing the application coders, allowing users of the application to modify
the
interface without hacking or forking your project, and a much quicker prototyping and
design
tool than modifying your C application directly.
===================================================================
RCS file: /cvsroot/enlightenment/e17/docs/edjebook/xml/positioning.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -3 -r1.1 -r1.2
--- positioning.xml 20 Feb 2004 08:22:10 -0000 1.1
+++ positioning.xml 1 Apr 2004 09:58:59 -0000 1.2
@@ -3,9 +3,9 @@
<para>
The Edje positioning model is based heavily on relativity, and is difficult for many
new users to adjust to. Simply put, every
-part defined is relative to something else and is positioned relative to it. If you
do not explicitly define what a part is
+part defined is relative to something else and is positioned relative to that thing.
If you do not explicitly define what a part is
relative to it is relative to the entire interface. The sections rel1 and rel2 are
present in every part description and
-define the positioning. Each part should be thought of as a container, and the
contents of the part whether may not neccisarily
+define the positioning. Each part should be thought of as a container, and the
contents of the part may not necessarily
fill the entire container. Thus we can think of the interface itself as a container,
which simply contains other containers.
rel1 defines the positioning of the top left corner of the part container, and rel2
defines the positioning of the bottom right
corner of the part container. Doubles are used with the keyword relative ranging
from 0.0 to 1.0 representing a percentage of left-to-right
@@ -24,7 +24,7 @@
On top I have provided an Edje compass which is a helpful tool to visualize
positioning. Looking at the compass, notice that the left and northern
directions approach 0.0 moving negatively, and that the right and southern directions
approach 1.0 moving in the positive direction. Again, this
is because everything starts from the top left corner of the parent container,
regardless if that parent container is the entire interface or just
-another part. So the part in the middle of our figure would be positioned starting
at roughtly 0.4 0.4, not 0.5 0.5. 0.5 0.5 would place
+another part. So the part in the middle of our figure would be positioned starting
at roughtly 0.4 0.4, not 0.5 0.5. A position of 0.5 0.5 would place
the top left corner of the part exactly in the middle of the interface, not center
entire part. To better illistrate this lets look at some
examples as you would see them in an EDC.
</para>
@@ -86,13 +86,13 @@
<para>The second part in the example above is very similar to the "background" part,
it is not relative
to anything, and therefore is relative to the whole interface. However, notice that
an offset is specified
-for both rel1 and rel2. These values are possition modifiers specified in pixels.
These offsets are based
+for both rel1 and rel2. These values are position modifiers specified in pixels.
These offsets are based
on the positioning defined by the relative keyword. Again, the two arguments specify
horizontal positioning
followed by vertical. So by using an offset in rel1 of 10 10, we're moving the top
left corner of the part
(rel1) by 10 pixels to the right and 10 pixels south of the position specified by
relative. In the same way,
rel2 is placed at the bottom right corner of the interface, and offset by 10 pixels
to the left (-10) and
-10 pixels north (-10). Remember that these values are negative because all
positioning origionates from the
-top left corner of the container, so in this case we move backward toward it making
the values negative.
+10 pixels north (-10). Remember that these values are negative because all
positioning originates from the
+top left corner of the container, so in this case we move backward thus making the
values negative.
</para>
<para>
@@ -108,8 +108,8 @@
<para>
To create a line of buttons in Edje we are presented with some positioning decisions
to make. Each button could
be positioned absolutely to the corners of the interface, or instead the first button
would be positioned absolutely and
-each following button positioned relative to the first. Which method is right for
your interface is important descision
-as it will effect the ammount of effort needed to modify the interface later if you
choose or if you move those parts using
+each following button positioned relative to the first. Which method is right for
your interface is an important decision
+as it will effect the amount of effort needed to modify the interface later or if you
move those parts using
a program. If you position each button relative to the first you only need to move
the first buttons position to move them
all as opposed to moving each button individually. In this way we can group parts
together to make them act in a unified
positioning manner.
@@ -163,30 +163,26 @@
</figure>
<para>In this example we have two buttons. Looking at "button1" we see it's top left
corner (rel1) is positioned at the top left
-corner of the interface (relative) and then offset 10 pixels to the right and 10
pixels south (offset). It's bottom right corner (rel2)
+corner of the interface (relative) and then offset 10 pixels to the right and 10
pixels south (offset). Its bottom right corner (rel2)
is relative to the top left corner of the interface as well, but then offset 30
pixels to the right and 20 pixels south. We position
-both corners from the top left corner instead of from both the top left and bottom
right corner of the interface because since we are using
-static offsets we want to ensure the button stays in the same place even if the
interface is resized. Notice we are not specifying the
+both corners from the top left corner instead of from both the top left and bottom
right corner of the interface. This is a result of using
+static offsets, we want to ensure the button stays in the same place even if the
interface is resized. Notice we are not specifying the
min and max size of either buttons, all sizing is happening based on the position of
the corners of that part. The result of the positioning
scheme used for "button1" is a container that stretches from the top left corner and
is 20 pixels wide and 10 pixels high. If we had specified
a min and max size for the part of 10 pixels the rectangle would only fill half of
the container, and unless an "align" keyword was used that rectangle
would start from the top left corner of the container like everything else, thus the
left side of the container would be filled with rect and the other
half of the container empty.</para>
-<para>Button2 in our example uses the "to" keyword in both rel1 and rel2. The top
left corner of "button2" is positioned at the right top corner of "butt
-on1",
-because rel1 is relative to "button1" and the relative keyword specifies that the top
left corner of this part is relative to 1.0 0.0 of it. An offset is
+<para>Button2 in our example uses the "to" keyword in both rel1 and rel2. The top
left corner of "button2" is positioned at the right top corner of "button1",
+because rel1 is relative to "button1" and the relative keyword specifies that the top
left corner of this part is relative to 1.0 0.0 of "button1". An offset is
also used, which moves the "button2" container to the right by 10 pixels
horizontally, which is going to act as the button spacing. The bottom right
corner (rel2) is again positioned relative to "button1" but this time relative to
"button1"s bottom right corner. An offset of 30 pixels is used which
-provides 10 pixels for our button spacing, and then another 20 pixels for the
containers width. In the end this gives us two buttons space 10 pixels apar
-t
-that are 20 by 10 pixels in size. If we wanted to add another button we'd make it
relative to "button2" so that each button is relative to the next which
- is
-positioned ultimately by the first button.
+provides 10 pixels for our button spacing, and then another 20 pixels for the
containers width. In the end this gives us two buttons spaced 10 pixels apart
+that are 20 by 10 pixels in size. If we wanted to add another button we'd make it
relative to "button2" so that each button is relative to the next all of
+which are positioned ultimately by the first button.
</para>
-<para>Suppose we wanted to create a button bar, but rather than using static buttons
like in the last example we simply wanted them to fill the width of t
-he
+<para>Suppose we wanted to create a button bar, but rather than using static buttons
like in the last example we simply wanted them to fill the width of the
interface completely reguardless of how large or small it was resized. In this case
we could use something like the following example.
</para>
@@ -238,11 +234,11 @@
<para>In this example we are creating two buttons and positioning them relative to
the interface. The first button defines its container
from the top left corner of the interface (rel1) over to the middle of the interface,
and 30 pixels south of the middle top (rel2).
The second buttons container starts half way across the top of the interface (rel1)
and extends the rest of the way across the interface and
-south by 30 pixels (rel2). So we have two buttons that fill the entire width of the
interface and is 30 pixels in height. No matter how
+south by 30 pixels (rel2). So we have two buttons that fill the entire width of the
interface and are 30 pixels in height. No matter how
thin or wide we resize the interface the button bar will look exactly as it
should.</para>
<para>If we wanted to modify the example to place the button bar on the bottom of the
interface we would change the veritcal parameter of the
relative keywords from 0.0 to 1.0 placing everything relative to the bottom of the
interface, leaving the horizontal parameters alone and then
-changing our offsets from a posative 30 pixels to a negative 30 pixels in order to
push back upward rather than down.</para>
+changing our offsets from a posative 30 pixels to a negative 30 pixels in order to
push them upward rather than down.</para>
</chapter>
===================================================================
RCS file: /cvsroot/enlightenment/e17/docs/edjebook/xml/preview.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -3 -r1.1 -r1.2
--- preview.xml 20 Feb 2004 08:22:10 -0000 1.1
+++ preview.xml 1 Apr 2004 09:58:59 -0000 1.2
@@ -2,9 +2,9 @@
<title>The Edje Preview Program</title>
<para>
-The <command>edje</command> program serves provides an easy to use tool for
previewing, testing and debugging EDCs.
+The <command>edje</command> program provides an easy to use tool for previewing,
testing and debugging EDCs.
The tool accepts two arguments, the first is the name of the EET to use, the second
is an optional argument specifying
-the Edje group to use specified within the EDC. If no group name is supplied you
will be presented with a list of
+the Edje group to use within the EDC. If no group name is supplied you will be
presented with a list of
all the groups within the specified EET, you may click on one of the groups to
preview it.
</para>
===================================================================
RCS file: /cvsroot/enlightenment/e17/docs/edjebook/xml/programs.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -3 -r1.1 -r1.2
--- programs.xml 20 Feb 2004 08:22:10 -0000 1.1
+++ programs.xml 1 Apr 2004 09:59:00 -0000 1.2
@@ -4,8 +4,8 @@
<para>Programs define how your interface reacts to events. These events can come
from Edje, user interaction, or
an external force like your window manager. All these events come to Edje as
signals. Signals from user interaction
would include mouse clicks, key presses and mouse movement. Signals from an external
source would include window
-moves, window resizes, window raises and lowers. And signals from Edje internally
would include programs starting or
-stopping, and the loading an EET. Each signal must come from some place, whether it
is a part or another program or
+moves, window resizes, or window raises and lowers. Signals from Edje internally
would include programs starting or
+stopping, or the loading of an EET. Each signal must come from some place, whether
it is a part or another program or
in the case of a window manager move anywhere. The place from which a signal come is
known as the source. If
a user left clicks on an image part named "button", a "mouse,clicked,1" signal is
generated from the source part "button".
</para>
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
enlightenment-cvs mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs
