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.