Diffstat (limited to 'PaintLocking')
1 files changed, 12 insertions, 12 deletions
diff --git a/PaintLocking b/PaintLocking
index 0b18e1d..dee267b 100644
@@ -7,15 +7,15 @@ Locking paint window paint attributes
1. About this document
This document is more a quick overview than an in-depth description.
-The functions are well documented in the code, please read them for more
+The functions are well documented in the code. Please read them for more
In this document, paint attributes are opacity, saturation and brightness.
-They also deal with CompWindow's not, for instance, cube transparancy.
+They also deal with CompWindows, not, for instance, cube transparency.
2. Basic design
-We assume there are three fundamentally diffrent ways to change paint
+We assume there are three fundamentally different ways to change paint
attributes. These are:
- Human change or external program. These should get precedence.
@@ -23,7 +23,7 @@ attributes. These are:
- Plugin wanting a temporary effect.
To facilitate these three diffrent cases, we store paint-values two
-plces. They are stored in w->paint, which is the actual paint values
+places. They are stored in w->paint, which is the actual paint values
used, and they are stored in w->opacity/saturation/brightness (I'll use
w->opacity though all three apply from now on).
@@ -36,21 +36,21 @@ The way we do things now, we use w->opacity as a default value, and
w->paint.opacity as the real value. We try to avoid using paintWindow()
to change the opacity.
-A plugin that wish to temporarily change the opacity, will do so by
-modifying w->paint.opacity, and when it is finished, it wil set
+A plugin that wish to temporarily change the opacity will do so by
+modifying w->paint.opacity, and when it is finished, it will set
w->paint.opacity to w->opacity. While it is set, it will lock w->paint.opacity.
This lock is usually set to PL_TEMP_HELLO, which is a pseudo-lock. The
reason we don't use PL_NO_LOCK, is to avoid overriding the temporary change
when the default is changed.
-Now consider two plugins, trailfocus and opacify. Opacify is modifying opacity
+Now consider two plugins: trailfocus and opacify. Opacify is modifying opacity
on 5 windows, and we change focus. This causes trailfocus to change w->opacity
on these 5 windows, but the change isn't visible until opacify decides to reset
The assumption is that a user using trailfocus wants the opacity to be changed,
but also wants to use opacify. The default change will live "forever" because
-trailfocus allways affects the opacity. As a fallback, when we unload
+trailfocus always affects the opacity. As a fallback, when we unload
trailfocus, core supplies a bailout function that sets w->opacity to the
@@ -58,9 +58,9 @@ The diffrent levels of locking allow us to override other plugins. This is
used in state, and this is used when manually changing opacity. A user-initated
opacity change will change w->opacity and at the same time lock it so other
code, like trailfocus, is unable to change it. State has the ability to lock
-both the default and temporary/absoloute paint attributes. State simply
+both the default and temporary/absolute paint attributes. State simply
sets default and temporary paint attributes with PL_PLUGIN_ONE. Users may
-want to use this for ensuring their mplayer-window is allways opaque for
+want to use this for ensuring their mplayer windows are always opaque for
@@ -72,10 +72,10 @@ setWindowOpacity(CompWindow * w, GLushort opacity, PaintLockLevels lock);
resetWindowOpacity(CompWindow * w, PaintLockLevels lock);
set of functions (and the respective functions for brightness/saturation).
-You should not have to worry about return-values, though setWindowOpacity()
+You should not have to worry about return values, though setWindowOpacity()
will return true if it successfully sets the value.
-Generally, you use PL_TEMP_HELLO as the lock, state uses PL_PLUGIN_ONE. We
+Generally, you use PL_TEMP_HELLO as the lock, and state uses PL_PLUGIN_ONE. We
adjust lock levels on a case-by-case basis. There is really no more magic