Merge pull request #2264 from ixjlyons/i3bar-protocol-typos
Fix typos in documentation.
This commit is contained in:
commit
d68387bf5d
|
@ -593,7 +593,7 @@ optimize this and call +x_push_node+ on the appropriate con directly.
|
|||
itself for the container’s children. This function actually pushes the
|
||||
state, see the next paragraph.
|
||||
4. If the pointer needs to be warped to a different position (for example when
|
||||
changing focus to a differnt output), it will be warped now.
|
||||
changing focus to a different output), it will be warped now.
|
||||
5. The eventmask is restored for all mapped windows.
|
||||
6. Window decorations will be rendered by calling +x_deco_recurse+ on the root
|
||||
container, which then recursively calls itself for the children.
|
||||
|
@ -850,7 +850,7 @@ empty.
|
|||
Afterwards, +con_focus+ will be called to fix the focus stack and the tree will
|
||||
be flattened.
|
||||
|
||||
=== Case 3: Moving to non-existant top/bottom
|
||||
=== Case 3: Moving to non-existent top/bottom
|
||||
|
||||
Like in case 1, the reference layout for this case is a single workspace in
|
||||
horizontal orientation with two containers on it. Focus is on the left
|
||||
|
@ -877,7 +877,7 @@ container and the container above/below the current one (on the level of
|
|||
Now, +con_focus+ will be called to fix the focus stack and the tree will be
|
||||
flattened.
|
||||
|
||||
=== Case 4: Moving to existant top/bottom
|
||||
=== Case 4: Moving to existent top/bottom
|
||||
|
||||
The reference layout for this case is a vertical workspace with two containers.
|
||||
The bottom one is a h-split containing two containers (1 and 2). Focus is on
|
||||
|
|
|
@ -6,7 +6,7 @@ August 2012
|
|||
This document explains the protocol in which i3bar expects its input. It
|
||||
provides support for colors, urgency, shortening and easy manipulation.
|
||||
|
||||
== Rationale for chosing JSON
|
||||
== Rationale for choosing JSON
|
||||
|
||||
Before describing the protocol, let’s cover why JSON is a building block of
|
||||
this protocol.
|
||||
|
@ -233,7 +233,7 @@ name::
|
|||
instance::
|
||||
Instance of the block, if set
|
||||
x, y::
|
||||
X11 root window coordinates where the click occured
|
||||
X11 root window coordinates where the click occurred
|
||||
button::
|
||||
X11 button ID (for example 1 to 3 for left/middle/right mouse button)
|
||||
|
||||
|
|
2
docs/ipc
2
docs/ipc
|
@ -285,7 +285,7 @@ type (string)::
|
|||
Type of this container. Can be one of "root", "output", "con",
|
||||
"floating_con", "workspace" or "dockarea".
|
||||
border (string)::
|
||||
Can be either "normal", "none" or "1pixel", dependending on the
|
||||
Can be either "normal", "none" or "1pixel", depending on the
|
||||
container’s border style.
|
||||
current_border_width (integer)::
|
||||
Number of pixels of the border width.
|
||||
|
|
|
@ -109,7 +109,7 @@ run the tests on a separate X server instance (using Xephyr).
|
|||
|
||||
Xephyr will open a window where you can inspect the running test. You can run
|
||||
the tests without an X session with Xvfb, such as with +xvfb-run
|
||||
./complete-run+. This will also speed up the tests signficantly especially on
|
||||
./complete-run+. This will also speed up the tests significantly especially on
|
||||
machines without a powerful video card.
|
||||
|
||||
.Example invocation of complete-run.pl+
|
||||
|
@ -450,7 +450,7 @@ cmd 'focus left';
|
|||
is($x->input_focus, $left->id, 'left window focused');
|
||||
----------
|
||||
|
||||
However, the test fails. Sometimes. Apparantly, there is a race condition in
|
||||
However, the test fails. Sometimes. Apparently, there is a race condition in
|
||||
your test. If you think about it, this is because you are using two different
|
||||
pieces of software: You tell i3 to update focus, i3 confirms that, and then you
|
||||
ask X11 to give you the current focus. There is a certain time i3 needs to
|
||||
|
@ -614,7 +614,7 @@ activation, we decreased the total amount of time necessary to run all tests
|
|||
it significantly more attractive to run the test suite more often (or at all)
|
||||
during development.
|
||||
|
||||
An alternative approach to using socket activation is polling for the existance
|
||||
An alternative approach to using socket activation is polling for the existence
|
||||
of the IPC socket and connecting to it. While this might be slightly easier to
|
||||
implement, it wastes CPU time and is considerably uglier than this solution
|
||||
:). After all, +lib/SocketActivation.pm+ contains only 54 SLOC.
|
||||
|
|
|
@ -1372,7 +1372,7 @@ NetworkManager, VLC, Pidgin, etc. can place little icons.
|
|||
You can configure on which output (monitor) the icons should be displayed or
|
||||
you can turn off the functionality entirely.
|
||||
|
||||
You can use mutliple +tray_output+ directives in your config to specify a list
|
||||
You can use multiple +tray_output+ directives in your config to specify a list
|
||||
of outputs on which you want the tray to appear. The first available output in
|
||||
that list as defined by the order of the directives will be used for the tray
|
||||
output.
|
||||
|
@ -2204,7 +2204,7 @@ bindsym $mod+g exec i3-input -p 'goto ' -l 1 -P 'Goto: '
|
|||
---------------------------------------
|
||||
|
||||
Alternatively, if you do not want to mess with +i3-input+, you could create
|
||||
seperate bindings for a specific set of labels and then only use those labels.
|
||||
separate bindings for a specific set of labels and then only use those labels.
|
||||
///////////////////////////////////////////////////////////////////
|
||||
|
||||
[[pango_markup]]
|
||||
|
|
Loading…
Reference in New Issue