1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
|
Description: Use code-block instead bash directive and fix some typos
Author: Daniel Echeverri <epsilon@debian.org>
Forwarded: not-needed
Last-Update: 2025-01-19
--- a/docs/manual/how-to-migrate.rst
+++ b/docs/manual/how-to-migrate.rst
@@ -11,7 +11,7 @@
``LibCST`` are included below but it is recommended that you read their
documentation to familiarise yourself with the available functionalities.
-Stucture of a migration file
+Structure of a migration file
----------------------------
Migrations should be saved as a new file in ``libqtile/scripts/migrations``.
@@ -78,7 +78,7 @@
object. Therefore, if all your transformations can be performed in a single visitor, it is not necessary
to do anything further in the ``Migrator`` class.
-However, if you want to run mutiple visitors, transformers, codemods, this is possible by overriding the
+However, if you want to run multiple visitors, transformers, codemods, this is possible by overriding the
``run`` method of the ``_QtileMigrator`` class. For example, the ``RemoveCmdPrefix`` migrator has the following
code:
--- a/docs/manual/commands/navigation.rst
+++ b/docs/manual/commands/navigation.rst
@@ -6,7 +6,7 @@
As noted previously, some objects require a selector to ensure that the correct
object is selected, while other nodes provide a default object without a selector.
-The table below shows what selectors are required for the diferent nodes and whether
+The table below shows what selectors are required for the different nodes and whether
the selector is optional (i.e. if it can be omitted to select the default object).
.. list-table::
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -333,7 +333,7 @@
- Thermal zone widget.
- Allow TextBox-based widgets to display in vertical bars.
- Added a focused attribute to `lazy.function.when` which can be used to Match on focused windows.
- - Allow to update Image widget with update() function by giving a new path.
+ - Allow one to update Image widget with update() function by giving a new path.
* bugfixes
- Windows are now properly re-ordered in the layouts when toggled on and off fullscreen
@@ -419,7 +419,7 @@
still available in the qtile repo in /scripts.
Running `qtile` without arguments will continue to work for the
- forseeable future, but will be eventually deprecated. qtile prints a
+ foreseeable future, but will be eventually deprecated. qtile prints a
warning when run in this configuration.
- Qtile.cmd_focus_by_click is no longer an available command.
- Qtile.cmd_get_info is no longer an available command.
@@ -996,7 +996,7 @@
- Documentation is now in sphinx
- Several install guides for various OSes
- New widgets: battery based icon, MPRIS1, canto, current layout, yahoo
- weather, sensors, screen brightness, notifiy, pacman, windowtabs,
+ weather, sensors, screen brightness, notify, pacman, windowtabs,
she, crashme, wifi.
- Several improvements to old widgets (e.g. battery widget displays low
battery in red, GroupBox now has a better indication of which screen
--- a/docs/manual/hacking.rst
+++ b/docs/manual/hacking.rst
@@ -20,7 +20,7 @@
imagemagick>=6.8 imagemagick ``test/test_images*`` (optional)
gtk-layer-shell libgtk-layer-shell0 Testing notification windows in Wayland (optional)
dbus-launch dbus-x11 Testing dbus-using widgets (optional)
-notifiy-send libnotify-bin Testing ``Notify`` widget (optional)
+notify-send libnotify-bin Testing ``Notify`` widget (optional)
xvfb xvfb Testing with X11 headless (optional)
================= =================== ==================================================
--- a/docs/manual/howto/git.rst
+++ b/docs/manual/howto/git.rst
@@ -46,7 +46,7 @@
git checkout pr<id>
The numeric pull request id can be found in the url or next to the title
-(preceeded by a # symbol).
+(preceded by a # symbol).
.. note:: Having the feature branch checked out doesn't mean that it is
installed and will be loaded when you restart qtile. You might still need to
--- a/docs/manual/commands/advanced.rst
+++ b/docs/manual/commands/advanced.rst
@@ -131,7 +131,7 @@
from the new node. When a command is executed against a node, that command is
dispatched to the held command interface. The key decision here is how to
perform the traversal. The command client exists in two different flavors: the
-standard ``CommandClient`` which is useful for handling more programatic
+standard ``CommandClient`` which is useful for handling more programmatic
traversal of the graph, calling methods to traverse the graph, and the
``InteractiveCommandClient`` which behaves more like a standard Python object,
traversing by accessing properties and performing key lookups.
--- a/docs/manual/contributing.rst
+++ b/docs/manual/contributing.rst
@@ -86,7 +86,7 @@
then change it in a later patch. Please do a patch-by-patch review of your
PR, and make sure each commit passes CI and makes logical sense on its
own. In other words: *do* introduce your feature in one commit and maybe
- add the tests and documentation in a seperate commit. *Don't* push commits
+ add the tests and documentation in a separate commit. *Don't* push commits
that partially implement a feature and are basically broken.
.. note:: Others might ban *force-pushes*, we allow them and prefer them over
--- a/docs/manual/commands/shell/qtile-migrate.rst
+++ b/docs/manual/commands/shell/qtile-migrate.rst
@@ -63,7 +63,7 @@
------------------
Assuming your config file is in the default location, running ``qtile migrate``
-is sufficent to start the migration process.
+is sufficient to start the migration process.
Let's say you had a config file with the following contents:
--- a/docs/manual/config/groups.rst
+++ b/docs/manual/config/groups.rst
@@ -55,7 +55,7 @@
:class:`~libqtile.config.ScratchPad` is a special - by default invisible -
group which acts as a container for :class:`~libqtile.config.DropDown`
configurations. A :class:`~libqtile.config.DropDown` can be configured to spawn
-a defined process and bind thats process' window to it. The associated window
+a defined process and bind that's process' window to it. The associated window
can then be shown and hidden by the lazy command :meth:`dropdown_toggle` (see
:ref:`lazy`) from the ScratchPad group. Thus - for example - your favorite
terminal emulator turns into a quake-like terminal by the control of Qtile.
|
