Various manpage edits

Fix some spelling mistakes, missing punctuation and made some paragraphs more clear.
master
madblobfish 7 years ago
parent 45ec4de36a
commit 93fe8ae705

@ -11,8 +11,8 @@ sway-bar - bar configuration file and commands
Description
-----------
Sway allows for configuration of swaybar within the sway configuation file.
Swaybar commands must be used inside a _bar { }_ block in the config.
Sway allows configuring swaybar in the sway configuration file.
Swaybar commands must be used inside a _bar { }_ block in the config file.
Commands
@ -77,15 +77,15 @@ codes in this manner.
**activate_button** <button>::
Sets the button to be used for the _activate_ (primary click) tray item
event. By default is BTN_LEFT (0x110).
event. The default is BTN_LEFT (0x110).
**context_button** <button>::
Sets the button to be used for the _context menu_ (right click) tray item
event. By default is BTN_RIGHT (0x111).
event. The default is BTN_RIGHT (0x111).
**secondary_button** <button>::
Sets the button to be used for the _secondary_ (middle click) tray item
event. By default is BTN_MIDDLE (0x112).
event. The default is BTN_MIDDLE (0x112).
**tray_output** none|all|<name>::
Sets the output that the tray will appear on or none. Unlike i3bar, swaybar

@ -12,8 +12,8 @@ Description
-----------
Sway allows for configuration of libinput devices within the sway configuration file.
sway-input commands must be used inside a _input { }_ block in the config.
To obtain a list of available devices identifier, run **swaymsg -t get_inputs**.
sway-input commands must be used inside an _input { }_ block in the config.
To obtain a list of available device identifiers, run **swaymsg -t get_inputs**.
Commands
--------

@ -15,8 +15,8 @@ Security Overview
figured out yet. The following man page is provisional.
Securing sway requires careful configuration of your environment, the sort that's
usually best suited to a distro maintainer who wants to ship a secure sway
environment in their distro. Sway provides a number of means of securing it but
usually best suited to a distribution maintainer who wants to ship a secure sway
environment in their distribution. Sway provides a number of means of securing it but
you must make a few changes external to sway first.
Configuration of security features is limited to files in the security directory
@ -31,7 +31,7 @@ Environment security
--------------------
LD_PRELOAD is a mechanism designed to ruin the security of your system. There are
a number of strategies for dealing with this but they all suck a little. In order
a number of strategies for dealing with this, but they all suck a little. In order
of most practical to least practical:
1. Only run important programs via exec. Sway's exec command will ensure that
@ -50,8 +50,7 @@ compromised by LD_PRELOAD. It probably isn't, but you can be sure by setting
permit LD_PRELOAD for it (and will also run it as root, which sway will shortly
drop). You could also statically link sway itself.
Note that LD_LIBRARY_PATH has all of the same problems, and all of the same
solutions.
Note that LD_LIBRARY_PATH has all of these problems, and the same solutions.
Read your log
-------------
@ -93,16 +92,16 @@ policies. These features are:
Permission to take screenshots or record the screen.
By default, no permissions are granted (though saner defaults are provided in
/etc/sway/config.d/security). You can use the following config commands to control
/etc/sway/config.d/security). You can use the following configuration options to control
a program's access:
**permit** <executable> <features...>::
Permits <executable> to use <features> (each feature seperated by a space).
Permits <executable> to use <features> (each feature separated by a space).
<executable> may be * to affect the default policy, or the full path to the
executable file.
**reject** <executable> <features...>::
Disallows <executable> from using <features> (each feature seperated by a space).
Disallows <executable> from using <features> (each feature separated by a space).
<executable> may be * to affect the default policy, or the full path to the
executable file.
@ -154,7 +153,7 @@ a commands block and fill it with policies:
}
For example, you could do this to limit the use of the focus command to just
binding and critiera:
binding and criteria:
commands {
focus binding criteria
@ -210,7 +209,7 @@ You can also control which IPC events can be raised with an events block:
}
}
The following commands are vaild within an ipc events block:
The following commands are valid within an IPC events block:
**binding** <enabled|disabled>::
Controls keybinding notifications (disabled by default).

@ -62,16 +62,19 @@ commands with **swaymsg**(1) or **i3-msg**(1) (or even with **i3**(1), probably)
Configuration
-------------
If _-c_ is not specified, sway will look in several locations for your config
file. The suggested location for your config file is ~/.config/sway/config.
~/.sway/config will also work, and the rest of the usual XDG config locations
are supported. If no sway config is found, sway will attempt to load an i3
config from all the config locations i3 supports. Sway looks for a config file in
a fallback directory as a last resort, which is /etc/sway/ by default. A standard
configuration file is installed at this location. If still nothing is found,
you will receive an error.
To write your own config, it's suggested that you copy the default config file to
The path to a config file can be given via the _-c_ parameter, else
sway searches for it in the following locations:
- ~/.sway/config
- $XDG_CONFIG_HOME/sway/config (suggested location)
- ~/.i3/config
- $XDG_CONFIG_HOME/i3/config (XDG_HOME )
- /etc/sway/config
- /etc/i3/config
In /etc/sway/config the standard config file is installed.
An error is raised when no config file is found.
To write your own configuration, it's suggested that you copy the default config file to
the location of your choosing and start there.
For information on the config file format, see **sway**(5).

@ -73,7 +73,7 @@ They are expected to be used with **bindsym** or at runtime through **swaymsg**(
**focus** output <direction|name>::
Direction may be one of _up_, _down_, _left_, _right_. The directional focus
commands will move the focus to the output in that direction. When name is
given the focus is changed to the output with that name.
given, the focus is changed to the output with that name.
**focus** mode_toggle::
Toggles focus between floating view and tiled view.
@ -148,7 +148,7 @@ They are expected to be used with **bindsym** or at runtime through **swaymsg**(
through the windows in the scratchpad.
**split** <vertical|v|horizontal|h|toggle|t>::
Splits the current container, vertically or horizontally. If toggled then the
Splits the current container, vertically or horizontally. If toggled, then the
current container is split opposite to the parent container.
**splith**::
@ -185,10 +185,10 @@ or triggered at runtime.
**client**.<color_class> <border> <background> <text> <indicator> <child_border>::
The client commands control the colors of the view borders and title bars. All
of the client commands _require_ five color values. (The one exception is
client commands _require_ five color values. (The one exception is
**client.background** which _requires_ one color value.) If you only want to
specify a subset, supply default colors for all the others. Colors must be
defined in hex. i.e. _#rrggbb_ or _#rrggbbaa_ when including the alpha
defined in hex. i.e. _#rrggbb_ or _#rrggbbaa_, when including the alpha
channel.
+
The command tokens are:
@ -258,7 +258,7 @@ The default colors are:
Uses the container dimensions as default.
-1 x -1 will remove any restriction on dimensions.
0 x 0 has the same behavior as not setting any value.
If in conflict this option has precedence over floating_minimum_size.
If in conflict, this option has precedence over floating_minimum_size.
**floating_minimum_size** <width> x <height>::
Specifies the minimum dimensions of floating windows.
@ -338,8 +338,8 @@ The default colors are:
**mode** <mode_name>::
Switches to the given mode_name. The default mode is simply _default_. To
create a new mode in config append _{_ to this command, the following lines
will be keybinds for that mode, and _}_ on its own line to close the block.
create a new mode append _{_ to this command, the following lines
will be keybindings for that mode, and _}_ on its own line to close the block.
**mouse_warping** <output|none>::
When _output_: place mouse at center of newly focused window when changing
@ -352,7 +352,7 @@ The default colors are:
**output** <name> <resolution|res> <WIDTHxHEIGHT>::
Configures the specified output to use the given resolution.
+
_Note_: sway does not currently support modesetting. Your output's native
_Note_: sway does not currently support setting the output mode. Your output's native
resolution will be used and the screen will be scaled from the resolution
specified to your native resolution.
@ -399,12 +399,12 @@ The default colors are:
**unmark** <identifier>::
**Unmark** will remove _identifier_ from the list of current marks on a window. If
no _identifier_ is specified then **unmark** will remove all marks.
no _identifier_ is specified, then **unmark** will remove all marks.
**workspace** [number] <name>::
Switches to the specified workspace. The string "number" is optional. The
worspace _name_, if unquoted, may not contain the string "output", as sway
will assume that the command is moving a worspace to an output, as described
workspace _name_, if unquoted, may not contain the string "output", as sway
will assume that the command is moving a workspace to an output, as described
below.
**workspace** <prev|next>::
@ -438,9 +438,9 @@ A criteria is a string in the form of e.g.:
[class="[Rr]egex.*" title="some title"]
The string contains one or more (space separated) attribute/value pairs and they
are used by some commands filter which views to execute actions on. All attributes
must match for the criteria string to match.
The string contains one or more (space separated) attribute/value pairs. They
are used by some commands to choose which views to execute actions on. All attributes
must match for the criteria to match.
Criteria may be used with either the **for_window** or **assign** commands to
specify operations to perform on new views. A criteria may also be used to
@ -460,7 +460,7 @@ Currently supported attributes:
**class**::
Compare value against the window class. Can be a regular expression. If value
is _focused_ then the window class must be the same as that of the currently
is _focused_, then the window class must be the same as that of the currently
focused window.
**con_id**::
@ -485,7 +485,7 @@ Currently supported attributes:
**workspace**::
Compare against the workspace name for this view. Can be a regular expression.
If value is _focused_ then all the views on the currently focused workspace
If the value is _focused_, then all the views on the currently focused workspace
matches.
See Also

Loading…
Cancel
Save