Fix typos in declarative layout docs
This commit is contained in:
parent
65ec764416
commit
8bd0da5315
|
@ -1,13 +1,13 @@
|
||||||
# The declarative layout system
|
# The declarative layout system
|
||||||
|
|
||||||
This system provide an alternative to the system used in Awesome 3.5 and is
|
The declarative layout system provides an alternative to the imperative system.
|
||||||
inspired by the one once used by Awesome 3.2-3.4 and Qt QML system.
|
It is inspired by the one used by Awesome 3.2-3.4 and the Qt QML style.
|
||||||
|
|
||||||
## The default widgets
|
## The default widgets
|
||||||
|
|
||||||
### Widgets
|
### Widgets
|
||||||
|
|
||||||
Awesome provide 2 collections of widgets:
|
Awesome provides 2 collections of widgets:
|
||||||
|
|
||||||
* `wibox.widget`: Generic widgets, containers and layouts
|
* `wibox.widget`: Generic widgets, containers and layouts
|
||||||
* `awful.widget`: The Awesome specific widgets
|
* `awful.widget`: The Awesome specific widgets
|
||||||
|
@ -17,15 +17,15 @@ Awesome provide 2 collections of widgets:
|
||||||
|
|
||||||
### Containers
|
### Containers
|
||||||
|
|
||||||
Containers are widget wrapping another widget. It can be used to add decorations
|
A container is a widgets that wraps another widget. It can be used to add
|
||||||
or to modify the content of the child widget.
|
decorations or to modify the content of the child widget.
|
||||||
|
|
||||||
@DOC_container_WIDGET_LIST@
|
@DOC_container_WIDGET_LIST@
|
||||||
|
|
||||||
### Layouts
|
### Layouts
|
||||||
|
|
||||||
Layouts are collection of children widgets. They place them according to rules
|
Layouts are collections of children widgets. They are placed according to
|
||||||
and usually provide some options.
|
configurable rules.
|
||||||
|
|
||||||
@DOC_layout_WIDGET_LIST@
|
@DOC_layout_WIDGET_LIST@
|
||||||
|
|
||||||
|
@ -52,8 +52,8 @@ Code:
|
||||||
|
|
||||||
|
|
||||||
In this example `s == 1` is an inline expression. In the default `rc.lua`,
|
In this example `s == 1` is an inline expression. In the default `rc.lua`,
|
||||||
there is an `s` variable represent to define the current screen. Any lua
|
there is an `s` variable represent to define the current screen. Any Lua
|
||||||
logic expression can be used as long as it return a valid widget, or a
|
logic expression can be used as long as it returns a valid widget or a
|
||||||
declarative layout, or `nil`.
|
declarative layout, or `nil`.
|
||||||
|
|
||||||
|
|
||||||
|
@ -106,9 +106,9 @@ Result:
|
||||||
![Example2 screenshot](../images/widgetlayout1.png)
|
![Example2 screenshot](../images/widgetlayout1.png)
|
||||||
|
|
||||||
|
|
||||||
### Use an `wibox.layout.align` layout
|
### Use a `wibox.layout.align` layout
|
||||||
The `wibox.layout.align` is a little different. While most layouts will
|
The `wibox.layout.align` is a little different. While most layouts will
|
||||||
ignore any `nil` lines, the `align` layout rely on them so `left`, `middle`
|
ignore any `nil` lines, the `align` layout relies on them so `left`, `middle`
|
||||||
and `right` can be defined
|
and `right` can be defined
|
||||||
|
|
||||||
Code:
|
Code:
|
||||||
|
@ -144,7 +144,7 @@ Code:
|
||||||
Result:
|
Result:
|
||||||
![Example4 screenshot](../images/widgetlayout2.png)
|
![Example4 screenshot](../images/widgetlayout2.png)
|
||||||
|
|
||||||
For more information about how to draw widgets, refer to the `Cairo` api:
|
For more information about how to draw widgets, refer to the `Cairo` API:
|
||||||
|
|
||||||
* [Path](http://cairographics.org/manual/cairo-Paths.html)
|
* [Path](http://cairographics.org/manual/cairo-Paths.html)
|
||||||
* [Context](http://cairographics.org/manual/cairo-cairo-t.html)
|
* [Context](http://cairographics.org/manual/cairo-cairo-t.html)
|
||||||
|
@ -177,23 +177,23 @@ Code:
|
||||||
### Accessing widgets
|
### Accessing widgets
|
||||||
|
|
||||||
For each widget or container, it is possible to add an `identifier` attribute
|
For each widget or container, it is possible to add an `identifier` attribute
|
||||||
so the widget can be accessed later.
|
so that it accessed later.
|
||||||
|
|
||||||
Widgets defined using `setup` can be access by 3 means:
|
Widgets defined using `setup` can be accessed using these methods:
|
||||||
|
|
||||||
* Avoid the issue by using externally created widgets
|
* Avoiding the issue by using externally created widgets
|
||||||
* Use `my_wibox.my_first_widget.my_second_widget` style access
|
* Using `my_wibox.my_first_widget.my_second_widget` style access
|
||||||
* Use JavaScript like `my_wibox:get_children_by_id("my_second_widget")[1]`
|
* Using JavaScript like `my_wibox:get_children_by_id("my_second_widget")[1]`
|
||||||
|
|
||||||
The first method mixes the imperative and declarative syntax, but makes the code
|
The first method mixes the imperative and declarative syntax, and makes the code
|
||||||
less readable. The second is a little verbose and only works if every node in
|
less readable. The second is a little verbose and only works if every node in
|
||||||
the chain have a valid identifier. The last one doesn't require long paths,
|
the chain has a valid identifier. The last one doesn't require long paths,
|
||||||
but it is not easy to get a specific instance if multiple widgets have the
|
but it is not easy to get a specific instance if multiple widgets have the
|
||||||
same identifier.
|
same identifier.
|
||||||
|
|
||||||
WARNING: The widget identifier must not use reseved name. This include all
|
WARNING: The widget identifier must not use reserved name. This includes all
|
||||||
method names, existing widget attributes, `layout` and `widget`. Names should
|
method names, existing widget attributes, `layout` and `widget`. Names should
|
||||||
also respect the lua variable name policies (case sensitive, alphanumeric and
|
also respect the Lua variable conventions (case-sensitive, alphanumeric,
|
||||||
underscore characters and non-numeric first character)
|
underscore characters and non-numeric first character)
|
||||||
|
|
||||||
Code:
|
Code:
|
||||||
|
@ -220,10 +220,10 @@ Code:
|
||||||
|
|
||||||
This system is very flexible. Each section attribute (the entries with string
|
This system is very flexible. Each section attribute (the entries with string
|
||||||
keys) is directly linked to the layout or widget API. When setting the
|
keys) is directly linked to the layout or widget API. When setting the
|
||||||
imaginary `myproperty`, it will first check if `set_myproperty` exist. If it
|
imaginary `myproperty`, it will first check if `set_myproperty` exists. If it
|
||||||
doesn't, it will check if there is a `myproperty` method. Finally, it will
|
doesn't, it will check if there is a `myproperty` method. Finally, it will
|
||||||
just set the `mywidget.myproperty` directly in case it is used later or
|
just set the `mywidget.myproperty` directly in case it is used later or
|
||||||
catched by a lua `metatable` (operator overload).
|
caught by a Lua `metatable` (operator overload).
|
||||||
|
|
||||||
Code:
|
Code:
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue