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.
This function is not documented to handle userdata, but historically it
would just pass all arguments to gears.surface.load(), which interpreted
userdata as cairo surfaces. After 3295e9f33d, userdata
objects are restricted.
Accept userdata objects again by explicitly passing them to
gears.surface.load().
Fixes: https://github.com/awesomeWM/awesome/issues/2903
Signed-off-by: Uli Schlachter <psychon@znc.in>
The `:keys()` and `:buttons()` APIs moved from get/set single methods
to properties. It works fine if you use the new or old API, but has
limitations when mixing them. `awful.rules` calls properties in a loop
after checking if it is a function. Thus it triggers the secondary
codepath to try to handle this case.
This codepath was tested with gears.objects based components
(ie. widgets). It was not tested with clients and tags, and it
didn't work because they use `awful.tag.getproperty` and
`awful.client.property.get` instead of `._private` like all
newer components. Those old functions are officially deprecated,
but used by tons of configs and modules ported from v3.5 and thus
still the default way to access Lua properties in our implementation.
This commit adds a `_private` to anything that doesn't have one to
at least make the error stop. It will "mostly" work until a more
complete solution is added. Reverting the 2 PRs that changed this
would delay getting more feedbacks.
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.
This is done now because a lot of code in `lib/` add buttons by manually
extracting buttons from awful.button. Instead of adding ugly code to
prevent using the legacy API, do this.
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.
Many legacy Awesome APIs such as `client:tags()`, `root.buttons()`,
`client:keys()`, `drawin:geometry()`, etc used functions for both the getter
and setter. This contrast with just about everything else that came after
it and is an artifact of an earlier time before we had "good" Lua object
support.
Because both consistency and backward compatibility are important, this
table wrapper allows to support both the legacy method based accessors
and key/value based accessors.
It isn't part of the public API, has a sledgehammer function prototype
and is intended for internal use only.
It's ugly, but backward compatibility is more important than anything
else.
There is no better place to put it and need to always be required
for backward compatibility. Given Awesome no longer works properly
without `awful`, I put the code there.
The reason for this is that as more of CAPI is brought in line with the
current API guidelines, it is more and more likely the tests will hit
APIs shims (either to test them or because the prototype remains the
same and only the implementation moved to Lua).
The use case for this will be to detech which screen is connected to
an output from the screen rules.
It is in millimeters because this is what the output provides and in
inches because the DPI is based on that unit and screens are sold with
the size in inches on the box.
Identical viewports are already handled before getting into Lua,
but sometime xrandr gives another viewport that encompass all
others. It has to be removed.
When the screens are created from the viewport in Lua, the signal is
sent too early and the DPI and outputs have not yet been added. This
cause the `connect_for_each_screen` callbacks to be called with a
partially initialized screen object. It also causes the drawables to be
repainted too early.
CAPI now emits "_added" and "awful.screen" takes care of emitting
"added".
With this, there is plenty of palces where the DPI can be set before
those signals are sent. This allows wallpaper with the proper DPI to
work with screens created using `fake_add`. In turn, this will allow
screen rules to control the DPI. In "the past", the DPI used for those
handler was the native DPI of the screen with no opportunity to change
it before hand.
This is easier than messing with the `fake_resize()` method. This will
eventually have an awful.screen.rules equivalent to auto-split the
screen from the rules.
This doesn't mean removing all screens is supported. It isn't and never
will be. The only reason this commit exist is to allow some
initialization and error handling code to be tested.
This commit add an optional `--screen off` command to initialize Lua
without first adding the screens. This is inconvinient for most users
since it restrict the APIs that are usable out of the box.
However, this allows AwesomeWM to work independently from the hardware.
This means that when a screen is unplugged, it is the Lua code that will
remove the screen instead of CAPI pulling the carpet from under. It also
allows to ignore some screen areas before the screen is ever created.
Combined, it makes it possible to work with screens even when they are
physically disconnected. Finally, it will allow for an awful.rules like
API to control how screens are created.
All in all, some people need this for their setup and some people might
want to do it anyway for fine grained and/or dynamaic multi-screen
setups.
This commit also adds 4 new signals to `capi` to be able to
execute code at specific points during the initialization. The commit
improves naughty error notifications to work even if problems occurs
before the screens are added.
Note that AwesomeWM will exit if no screens are created. While it would
be easy to just call `refresh_screen();` after unsetting the magic
variable, doing so would have corner cases. Better be harsher and
prevent the user from shooting themselves in the foot from not reading
the f****** manual. Code introduced in future commits will take care
of automatically calling fake_screen in the event nothing is created.
Fixes#1382
This function allows to update the content of a table using the
content of a second table. It helps to keep the original reference
and to know what has been added and removed.
Add `dpi.lua` to config.ld even if it isn't added yet. This is
because the way the test run has it cached in the build dir. A full
rebuild would take too long and timeout on travis for semi-large PRs.
This code is inside an "if new_timeout and [something else]". Thus, it
only executes when new_timeout is "truthy". Thus, "new_timeout or
[whatever]" will always evaluate to "new_timeout".
This commit removes that tiny bit of dead code.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Technically this doesn't solve any memory leak, but AwesomeWM uses in
average less memory when changing the selected tab in quick succession.
This is because it has less "temporary" tables to track.
The way background are rendered changed to accomodate issues regarding
cliping and border. However this broke the documentation examples.
This commit fixes this in the least hacky way I found.
Fixes#2727
Nobody wants to set this parameter. It is necessary because the old
API allowed `awful.rules` to be used with random for random matching.
This stopped "really" working between the 3.4 and 3.5 release because
the code started to accumulate "corner case" fixes aligned with the
client properties. v4.0 added more ordering and v4.3 added external
sources. After this, it is unusable with external objects, but
`gears.matcher` handle this use case very well.
In a perfect world we would have pure expression matching, but
that's problematic with all the "metaness" of the code. For now,
this adds an imperfect way to match the minimum and maximum of
number properties.
It will be used by the screen rules for the DPI and size properties.
This is hardcoded in `awful.rules`, but cannot be shared due to the
priority corner cases. Given in the long run any "standard" priority
should use the topological sort API, better not try to share *that*
code.
It is now possible to add and remove rules. This is superior to how
`awful.rules` originally handled rules because modules can now
assume adding and removing rules works.
The reason for the methods rather than `table.insert` is partially
because future commits will add signals. In turn, this will allow
`gears.matcher` to be extended by module using it using the extra
"introspection" made possible by the signals.
The name is self explanatory, it adds more actions to a notification.
One of the use case is adding a snooze/reming_me action. Another one
is "mute similar notifications".
The reason is that if actions are provided by rules, only one instance
exist. It was a mistake to couple actions with their notifications. It
could not work reliably and has to be removed.
The commit also change the notification action storage to be a copy
instead of the original table. This allows to append actions (not part
of this commit) without risking adding them to the wrong notification.
**WARNING** This break an unreleased API by removing the `notification`
property of an action.
* app_name: To be used in filters when no clients are found.
* max_width: Allow to set it from the rules, it might be different
when a `widget_template` is used.
* widget_template: Now it can be set from the rules without further
boilerplate code.
The old preset code had a primitive implementation of the rule API
used in `naughty.dbus`. Now that `gears.matcher` is extracted from
`awful.rules`, it is possible to share the code.
The first step is to only enable the old API when the new
`request::preset` isn't connected. This is the same way the legacy
popup is only enabled when nothing is connected to `request::display`.
This removes the imperative "mutex" logic from rc.lua, where it doesn't
belong. It also makes it closer to the "vision" of making `rc.lua` fully
modular.
* action icons
* persistence
* residence
* categories
* animated icons
* more ways to get icons
In addition, the commit also tries its best to attach notifications to
objects using various dubious semi compliant hints or the DBus PID. It
works often enough to be useful.
Some titlebar widgets (`awful.titlebar.widget.titlewidget`,
`awful.titlebar.widget.button` and other specific button widgets) could
not be garbage collected until the associated client was unmanaged,
because the signal connection used to update the widget was never
destroyed, and the signal handling function was keeping a reference to
the widget in its environment. This resulted in high memory usage when
the titlebar widgets were recreated multiple times for the same client
(this does not happen with the default Awesome configuration, but may be
needed for dynamic titlebar reconfiguration in a custom config).
Modify the code to use weak tables instead of direct signal connections
to avoid keeping strong references to widgets. The widget update
functions still keep strong references to the widget itself (creating a
reference loop, but the Lua GC should handle it correctly) and the
client object, but this should not be a problem.
One publicly visible change is that `awful.titlebar.widget.titlewidget`
now has an `update` function, like the button widgets.
Signed-off-by: Sergey Vlasov <sigprof@gmail.com>
This is needed because if async code is run inside of a tooltip timer func the started property may not still be false.
The current version causes random spurious timer already started errors.
This is configurable globally or per-notification. When it is
replaced over dbus, it has a new timeout and *that* should be the
new timeout (starting when the notification is replaced).
Closes#2821
Emmanuel Lepage Vallee
Xinhao Yuan
mergify[bot]
Uli Schlachter
actionless
Jordan Christiansen
streetturtle
laith-m0
Uli Schlachter
Daniel Hahler
Sergey Vlasov
Robert Andrew Ditthardt