These are supposed to eventually replace the already-existing functions
in gears.surface which have a similar signature
Signed-off-by: Uli Schlachter <psychon@znc.in>
Adds a third parameter "timezone" to the textclock widget that is
optional. Defaults to local timezone if nil.
Signed-off-by: Matt Harrison <matt@harrison.us.com>
This commit changes the systray widget, wibox.drawable and the C code to
fix the following bug: When the systray widget is removed from a
drawable without being moved somewhere else, the systray stayed visible.
This was because the systray is not drawn by awesome, but only placed.
When the widget is no longer "drawn", it stays wherever it was placed
last.
This change works by detecting the situation when the systray is
removed. Then, the C code is specifically told to remove the systray
window from the drawable.
Note that this is only a partial fix. This change works correctly when
the widget is removed completely, because it is no longer placed by its
parent widget. However, for example, when you do
wibox.widget.systray().visible = false, the effect is just that the
systray widget gets size 0x0. This is not really visible, but as far as
this change is concerned, the widget is still part of the drawable.
Signed-off-by: Uli Schlachter <psychon@znc.in>
* Move table functions out of awful.util into new gears.table
* travis: Use v9999 prefix for full requests
Make sure no newly deprecated functions are used
* Move all `awful.util.table.*` calls to `gears.table.*` calls
Move table test functions from awful/util_spec to new gears/table_spec
Change awful.util.subsets call to gears.math.subsets in awful/key.lua
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>
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.
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>
It was set as `module` instead of `class` because ldoc was confused
set shown the methods as functions and functions as methods.
This commit set the explicit section so ldoc don't gress (wrongly)
This makes it possible to have the systray only visible on the primary screen,
which is the new default value. This also makes it possible to configure
directly on which screen the systray should be visible.
This breaks the API in the sense that people who use "the old method" to
configure the systray's screen possibly don't have a systray.
Fixes: https://github.com/awesomeWM/awesome/issues/724
Signed-off-by: Uli Schlachter <psychon@znc.in>
There's no point in having multiple instances of this, because there are no
per-instance settings and the systray can only be visible in a single place at a
time anyway.
Signed-off-by: Uli Schlachter <psychon@znc.in>
* Better widget names when using the declarative syntax
* Add ratio.get_ratio to avoid using the private API
* Also support `set_widget` when swapping widgets
This commit makes these methods invoke the method on a widget in a protected
context. Thanks to this, e.g. the wibox and other widgets are protected from
errors in a child widget.
Additionally, fit_widget() now assumes 0 if a widget's :fit() method didn't
provide a number.
Signed-off-by: Uli Schlachter <psychon@znc.in>
I just spent too much time tracking down a bug that happened while drawing a
widget. This is the reason why we should apply sanity checks while widgets are
constructed, so that we get a useful backtrace.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes the code use the existing functions for setting widgets. That way,
all the sanity checks that the existing functions have are applied for this code
as well.
I just spent half an hour tracking down a bug where a boolean ended up as a
"widget" in a fixed layout. The symptom was that while drawing the widget, an
error happened. Via this change, the error would instead be flagged while
constructing the widget.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit documents that a textbox already accepts a screen object where a
screen index is expected. Also, this changes the widget API in that a widget's
context.screen is now a screen object instead of a screen index.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This new syntax is inspired by the Awesome widget 3.2-3.4 API. It
allow cleaner widgets declaration. The produced code is usually much
shorted and easier to read than wibox.widget imperative syntax.
There is already a hack into `awful.widget.common`. This system aim
to make the hack obselete while preserving the useful part.
I think this is also necessary to properly support SVG (with DPI
and resize).
Finally, Qt handle this using the QBrush concept, where you can have
programmatic patterns. Cairo doesn't have this concept, so there is no
"clean" way to have programmatic brushes.
Uli Schlachter
getzze
Matt
axujen
FireFish5000
Kevin Zander
Emmanuel Lepage Vallée
Uli Schlachter
MoreThanOneAnimal
Daniel Hahler
Daniel Hahler