Remove dependency to awful and remove get_cell_sizes function
Remove matrix and add superpose property
Update documentation, remove beautiful dep
Add insert, extend and remove columns and rows
Change x and y to horizontal and vertical
Creating a widget already sets a metatable (at least these days).
However, wibox.container.scroll overwrote this metatable with its own
metatable. This commit removes this overwrite.
Signed-off-by: Uli Schlachter <psychon@znc.in>
It should be called "align", but the name is already taken
It doesn't use awful.placement because it would break the dependency
graph.
Some cases previously required 2 wibox.layout.align layouts,
one for each axis. This is massively overkill to simply place
a widget at the center of a larger area.
This bridges between gears.shape and the shapes. So far, it does not try
to do any kind of anti-aliasing magic, so you get "steep edges".
Signed-off-by: Uli Schlachter <psychon@znc.in>
Up to now, a drawable always figured out the screen that it is on by
looking at its position. This causes memleak-like problems with wibars:
A wibar has a screen assigned, but its underlying drawable will end up
referring to another screen. Via this, we were managing to build a long
reference chain of screens and drawable that meant that none of the fake
screens that our test suite added could be garbage collected.
To fix this, add wibox.drawable._force_screen(s). After this function is
called, the normal screen detection based on the position is skipped and
instead the given screen is always used. This breaks the above reference
chain and things become garbage-collectable.
Also, this chains the drawable to the life time of the screen: When the
screen becomes invalid (.valid == false), the drawable will stop
redrawing.
Fixes: https://github.com/awesomeWM/awesome/issues/1237
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, the API to set the data that should be displayed was
:set_data(t) where t is a table. This table has the labels to use as its
keys and the numbers as its values. With this API, it was not possible
to influence the order in which the "pie pieces" were drawn.
This commit adds and uses a new API called :set_data_list(t). Here, t is
a table with integer keys and tables as values, thus one can iterate
over this with ipairs() and the order is well-defined. The tables used
as values contain the label as their first entry and the number as their
second entry.
Fixes: https://github.com/awesomeWM/awesome/issues/1249
Signed-off-by: Uli Schlachter <psychon@znc.in>
It does not provide much value. The version number is already known to
ldoc globally in the "description" variable.
Signed-off-by: Uli Schlachter <psychon@znc.in>
No idea what self referencing loops this refers to. Lua 5.1's and
LuaJIT's garbage collector both should handle cycles just fine. Things
only start getting complicated when you start using weak tables.
Unless someone comes up with an example where this patch causes a leak,
let's remove the weak table magic.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Matrix operations are hard. Apparently I always keep confusing the order
that transformations are applied in the matrix resulting from a matrix
multiplication.
This commit fixes things in wibox.hierarchy that were wrong due to the
wrong order and changes a unit test so that it would now catch the
breakage (and makes sure that it does not happen again).
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of matrix_to_device and matrix_to_parent, this now provides the
full hierarchy instance managing the current widget.
In addition to x, y, width and height (which are an over-approximation
of the widget's extents on the drawable), this now also provides
widget_width and widget_height in the widget's local coordinate system.
These last two values are exact.
For example, the tooltip needs x/y/width/height while a widget that
wants to figure out which point on it was hit with a mouse press will
need widget_width and widget_height (together with the position argument
that is passed in with mouse::press).
I don't know how to document the return type of this function properly.
Hopefully just describing the structure of the resulting table is good
enough.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Similar to the previous commit, this makes the drawable not apply a
pending relayout while it is not visible. When it becomes visible again,
the relayout is done.
The hope here is that less work is done while a drawable is not visible,
saving CPU time.
Signed-off-by: Uli Schlachter <psychon@znc.in>
LGI does not protect against use-after-free issues that can occur due to
using an object after finalisation. This manifests itself as occasional
crashes on Travis in cairo_region_union_rectangle() (AFAIK no one ran
into this issue in real-world usage).
Since visible drawables are always strongly reachable, the issue can
only occur with invisible drawables. The previous commit made sure that
those are fully repainted when they become visible, so we can just
ignore redraws for those and fix the crash issue.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of tracking all drawables that are alive, the code now only
tracks visible drawables. When a drawable is made visible it is
completely repainted. This should not cause a difference when a wibox is
initially made visible, because it has to be redrawn anyway. However,
this introduces a full repaint when a wibox is hidden and then made
visible again.
Thanks to this change, we can stop using weak tables. Visible drawables
cannot be collected and so we can keep a strong reference to them. This
allows us to get rid of the weak tables which solves various problems
involving finalizers and using objects after finalisation.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This new function is called whenever the visibility of the drawable
changes. Later commits can use this for explicitly tracking the lifetime
of drawables instead of using magic weak tables.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This restore a feature that was available in Awesome 2.1-3.2.
The reason margin is implemented rather than use a container is to
be able to make the background smaller than the bar.
The current progressbar code dates from a time when Awesome had
a very limited drawing API. This commit first re-write the
algorithm to remove the workaround used to draw the border using
full rectangles only. It then add support for outer and inner
shapes with their respective border settings.
This commit also add clip support. This is enabled by default, but
could be disabled to have the bar taller than the background.
Twice now we had problems with the garbage collector which caused signals
established via weak_connect_signal() not to be disconnected when we wanted them
to be disconnected. The effect was that we tried to redraw a drawable after it
was garbage collected which caused errors.
Instead of playing whack-a-mole with all the various ways that might make us
redraw a drawable after GC, let's just fix all of these issues by explicitly
checking for this case and turning it into a no-op.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The previous commit made wibox.drawable turn a "normal redraw" into a complete
repaint when it was moved to another screen. However, nothing happened until
that normal redraw.
This commit triggers a normal redraw when we are (possibly) moved to another
screen. More precise, this means that whenever a screen appears, disappears or
changes its geometry and when the drawable is moved, we trigger a normal redraw.
This redraw will likely do nothing, because no relayout is pending and no part
of the surface needs a redraw, so it is cheap.
However, if the drawable really ends up on another screen, then the code from
the previous commits makes us do a full relayout and redraw.
This commit likely fixes the current instability of test-screen-changes.lua. See
https://github.com/awesomeWM/awesome/issues/982#issuecomment-231712056.
As explained there, the test fails because the fake screen that it created is
still referenced, so cannot be garbage collected, but the test doesn't succeed
unless the screen is garbage collected. So something is still referencing the
screen that was removed. This something can be a client's titlebar, because the
underlying drawable still has a context member referring to the old screen.
This commit should fix that problem, because we now trigger a redraw which will
compute a new context and thus the reference to the old screen is released.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The previous commit made the hierarchy do a re-layout when the context changes.
However, widgets could change their appearance depending on the context without
changing their layout. Thus, the previous commit is not enough.
This commit also makes the drawable redraw everything when the context changes.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When the context for widget changes (e.g. we are on a new different screen or
have a different DPI value), widgets might change their appearance even though
they didn't emit widget::layout_changed. Thus, update the hierarchy in these
cases.
Signed-off-by: Uli Schlachter <psychon@znc.in>
widget_at() no longer exists since 0aa4304bda (and the surrounding commits
stopped us using this function).
Signed-off-by: Uli Schlachter <psychon@znc.in>
The actual bg is drawn either with fake transparency over the wallpaper (this
uses operator OVER) or for true transparency with operator SOURCE. The bgimage
should be drawn ontop of this without erasing the background and thus needs
operator OVER.
However, before this commit the bgimage was drawn in the same way as the bg and
thus inherited its SOURCE operator if a compositor is running. Fix this by
restoring the default operator (OVER) and also e.g. the default source before
drawing the bgimage.
Fixes: https://github.com/awesomeWM/awesome/issues/954
Signed-off-by: Uli Schlachter <psychon@znc.in>
When called with the file name of an image, this function failed to turn that
file name into a cairo surface.
Fixes: https://github.com/awesomeWM/awesome/issues/954
Signed-off-by: Uli Schlachter <psychon@znc.in>
The requirement to call add_signal() was added to catch typos. However, this
requirement became increasingly annoying with property::<name> signals and e.g.
gears.object allowing arbitrary properties to be changed.
All of this ended up in a single commit because tests/examples fails if I first
let add_signal() emit a deprecation warning.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Uli Schlachter
getzze
Kevin Zander
Daniel Hahler
Lego Stax
Emmanuel Lepage Vallee
Uli Schlachter
Holger Schurig
MoreThanOneAnimal
Daniel Hahler
Salorium