--- CoreStructures | 12 ++++++------ Multihead | 4 ++-- PluginDevelopment | 2 +- 3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/CoreStructures b/CoreStructures index 7c859d6..234c00e 100644 --- a/CoreStructures +++ b/CoreStructures @@ -51,7 +51,7 @@ You can only input to one screen at the time, but output to multiple. 3. CompDisplay ============== -CompDisplay is mostly dealt with by core. It is the DataStructure that glues +CompDisplay is mostly dealt with by core. It is "the" data structure that glues all the possible screens together. Chances are, you will mostly just work with d->activeWindow which defines the currently active (focused) window, and the d->pointerX/Y which tells you where the pointer is. Also, it stores the atoms @@ -75,7 +75,7 @@ you call findScreenAtDisplay(). 'height' and 'width' is the height and width of the entire screen. It is very tempting to use these a lot, but they are dangerous. The reason they are dangerous is that they span across all heads associated with that screen. -Therefore, you want to familiarise yourself with the CompOutput structure. +Therefore, you want to familiarize yourself with the CompOutput structure. The CompScreen has an array of nOutputDev CompOutput structures; in other words, one per monitor. It also has a convenient currentOutputDev which core tries to set, but is not always accurate. @@ -104,21 +104,21 @@ area of the screen that should not be covered by windows, usually because it is covered by a panel. So when do you use s->width and when do you use -s->outpudDev[s->currentOutputDev].region.x1/x2 ? There is no universal answer +s->outputDev[s->currentOutputDev].region.x1/x2 ? There is no universal answer to this, but the simple answer is to use s->width when you are concerned with the entire screen, and the outputDev when you want to constrain yourself to the monitor. Examples are maximization, which deals with outputDev, and edge- detection, which wants to find the edge of the screen, not the monitor. Snapping wants to snap to the edge of the head, and so on. -More obvious variables are hsize and vsize, which define the horisontal +More obvious variables are hsize and vsize, which define the horizontal and vertical size, x and y, which define which of these you are currently on, screenNum, which defines which screen you are on (usually 0), and the WorkArea rectangle, which defines the work area for the screen (avoid using this, as it will be quite strange on bigscreen-hinted multihead, specially for -asymetric resolutions) +asymmetric resolutions) -Here's a drawing of an asymetric multihead setup: +Here's a drawing of an asymmetric multihead setup: +--------+-------------+ | | | | A | | diff --git a/Multihead b/Multihead index 7f428e4..5e8c6e3 100644 --- a/Multihead +++ b/Multihead @@ -3,7 +3,7 @@ WARNING: Incomplete and possibly incorrect information follows. Multihead and beryl =================== 0. Scope of this document -1. Two fundamentally diffrent ways of doing multihead +1. Two fundamentally different ways of doing multihead 2. What Compiz needs from X 3. Code-related concerns. @@ -14,7 +14,7 @@ This document is meant mainly for developers or advanced users. It does not cover configuration of X for specific video cards or situations. It is meant to explain how Beryl deals with multihead, not how you set up X. -1. Two fundamentally diffrent ways of doing multihead +1. Two fundamentally different ways of doing multihead ===================================================== Multihead is when more than one monitor, projector, tv, etc (head) is hooked up to the same computer. diff --git a/PluginDevelopment b/PluginDevelopment index fef9246..a3cfbb8 100644 --- a/PluginDevelopment +++ b/PluginDevelopment @@ -126,7 +126,7 @@ top of each other, so when you wrap a function, you're most likely saying order is essential when creating effects that persist through different plugins, like the fade plugin which looks at the intended opacity for a window paint and modifies it so instead of an instant change, we get a -smooth gradual change, regardless of wether it was an other plugin that +smooth gradual change, regardless of whether it was an other plugin that modified the opacity, or core. Unfortunately, there are far too many wrappables to explain them all here. -- 1.6.0.6 _______________________________________________ Dev mailing list [email protected] http://lists.compiz-fusion.org/mailman/listinfo/dev
