THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#1296 - Updated signal causes total relayout
User who did this - Uli Schlachter (psychon)
----------
TL;DR: I'd be interested in suggestions for the API.
Once again, here is a new version (mostly bugfixes). And once again, here is
the API that a widget can implement:
- widget:fit(width, height): As before, given a space of width x height, this
widget should return its desired width and height
- widget:draw(wibox, cr, width, height): As before, the widget should draw
itself on the cairo context cr in the are from (0, 0) having size (width,
height)
- widget:before_draw_children(wibox, cr, width, height) and
widget:after_draw_children(wibox, cr, width, height): These are called
before/after children are painted. before_draw_children is basically the same
thing as draw and exists just for consistency. Here the widget can e.g. call
cr:set_source_rgb(0,1,0) to influence its children. And after_draw_children()
could be used for... things. Someone will come up with a use! ;-)
- widget:layout(width, height): This returns the layout of the children of the
widget. This should return a list of widget placements. Such a placement can be
generated via base.place_widget(widget, matrix, width, height) where Matrix is
a cairo matrix that describes placement and rotation of the widget inside of
its parent's area. Most commonly such a matrix should come from
require("lgi").cairo.Matrix.create_translate(x, y) to place a widget at (x, y).
In contrast to the current area, none of these callbacks are recursive / should
call other widgets. The wibox code does all of that for us.
If a widget needs to be redrawn, but neither its :fit() nor :layout() changed,
then it should emit widget::redraw_needed.
If a widget's layout changed, it has to call widget::layout_changed. Only if
the result of its :fit() or :layout() actually changes will its :draw() also be
called, else it is assumed that no redraw is needed.
A BVH tree is an implementation detail, I'm mostly curious what exactly you
mean with "a widget can claim any space on the wibox". Or rather, how that
translates into API.
----------
One or more files have been attached.
More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4199
You are receiving this message because you have requested it from the Flyspray
bugtracking system. If you did not expect this message or don't want to
receive mails in future, you can change your notification settings at the URL
shown above.
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
