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.
Try both legacy and standardized code paths. Also try invalid mixes of
them in case some modules abuse of rc.lua and ingest the wrong format
by accident.
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.
This isn't very nice and pulls all sort of almost useless code into
the shims, making them less atomic. However the next few commits
will start another round of API standardization and the compatibility
layer wont be optional anymore.
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).
Uli Schlachter
actionless
mergify[bot]
Jordan Christiansen
Emmanuel Lepage Vallée
streetturtle
Aire-One