Just like 5 years ago, the dependency mess caused by the giant
`awful.client`, `awful.tag` and `awful.placement` requires to
split the code into small files with less dependencies and include
those.
In this case, the goal is to use the `awful.mouse.client` functions
from `awful.client`.
`awful.client` was only used once and the function exists as a
screen method. This will help untangle the dependencies a bit...
To tangle them even more after that...
This is the first commit of a new API to add and remove buttons
and keys from clients. The goal is to get rid of the default `rc.lua`
"hardcoded" list of client buttons and keys to allow modules to modify
the defaults. This is part of the larger effort to make `rc.lua`
modular.
Change how wibox are drawn to build a more flexible function reusable in the context of clients.
Add `clients` option to the template. This new option needs an associative table `{ ['label'] = client }` to work. Where label will be a text rendered on the middle of the client area.
Add a new example: `texts/examples/screen/tiled_clients.lua`.
Before this commit, the code directly modified the table where the tag's
properties were saved. This commit changes the code to call
awful.tag.setproperty() instead. This function ensures that
property::screen is now also emitted.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Another step in moving these APIs toward the common object oriented and
declarative paradigms used by other APIs.
This commit introduces the `awful.keyboard` module. It currenly only
exists as a placeholder for the first few append/remove function, but
will grow in scope in another pull request to expose the currently
private modifier APIs and to provide keybindings collision detection
and replace some of `awful.hotkey_popup` business logic.
The `keygrabber` tests which uses root keybindings are disabled for
now to keep the commit size small. This is necessary since the shims
will need many iterations of changes before this work again with the
new syntax.
It might not be the most pretty of change, but it works. With this
change, it is possible to have multiple "things" in the "same"
section having the "same" name.
This allows for C/C++ style functions with the same name but different
signatures. Lua doesn't handle this well, so it should usually be
avoided. However, constructors might be a valid exception. Most older
widget (and object) constructors have multiple random argument while
newer one use `args`. Deprecating the old ones for the sake of
standardization might be a bit too much for users upgrading from v3.5.
Given the only reason all of those deprecation would happen is because
"its pretty that way", then lets allow 2 constructors and avoid outrage.
The fix focuses on ewmh.merge_maximization function, which handles client intentions to change maximization states.
The fix includes:
1. Fixing the `get_value` helper function to return the proper resulting state that client wanted to change.
For example, when `c.maximized and not c.maximized_horizontal and not c.maximized_vertical` holds,
the client would observe the `MAXIMIZED_VERT` and `MAXIMIZED_HORZ` atoms in X11, but get_value would compute
the result values based on `c.maximized_{horizontal,vertical}`, which are all false. The fix makes the computation
consistent to clients' view.
2. Interpret a client's maximization intentions based on the client's view of how the X11 atoms changes.
Having buttons without an awful.util.table.join/gears.table.join
has never been officially documented to be supported. I hope there
isn't too many of those and they wont try to mix the new and old
API syntax, because that will totally break.
Now always call both check_widget and make_widget_from_value. This
should make it a lot less confusing when randomly trying to create
a widget as all ways to do it slowly converge toward an unified
one.
Emmanuel Lepage-Vallee
Seth Barberee
mergify[bot]
Aire-One
Uli Schlachter
James Reed
Xinhao Yuan
actionless
streetturtle