[awesome bugs] #1296 - Updated signal causes total relayout (Attachment added)
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) -- Sorry, but I think that the padding should be returned from :layout() instead of :fit(). New version attached where layout returns a list of children and the padding for this widget. -- 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#comment4210 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 [email protected].
[awesome bugs] #1296 - Updated signal causes total relayout (Attachment added)
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)
--
It's time for a new version!
This one adds an API change to make Elv13 (hopefully) happy:
- widget:fit(width, height) now not only returns its desired width and height,
but also a third (optional) value: padding! The padding is a table that can
contains keys "left", "right", "top", "bottom" (each optional). Each value is
the number of pixels that should be additionally included in the clip area when
the widget is redrawn. So if you return { bottom = 10 }, the widget will get 10
more pixels to the bottom than what the layout decided for it. And all of this
works with any transformation, so you can scale such a widget by factor 1.5 and
rotate it by 45° and still the right result (well, it will include 15 pixels of
space due to the scaling, so the unit isn't really "pixels" but "user space
units")
Hopefully this is enough for any kind of glow effect, but don't forget that
other widgets could draw to that space before or after you, so weird results
can occur...
(Implementation details: In a widget hierachy, each node knows the padding for
its own widget and the padding including all the padding of its children. This
is used so that a repaint knows which parts of the hierachy it can skip and to
clip each widget to its padding)
--
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#comment4209
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 [email protected].
[awesome bugs] #1296 - Updated signal causes total relayout (Attachment added)
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 [email protected].
[awesome bugs] #1296 - Updated signal causes total relayout (Attachment added)
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) -- Yet another new version of this proof of concept. Now, after re-layouting things, only the part of the wibox which really changed are redrawn. I bet this breaks Elv13's "let's ignore the widget's bound and unset the clip"-magic. I also fixed things so that the wibox code automatically emits widget::layout_changed on parent widgets when it is emitted on a child. (There is still potential for optimizations: If a widget is visible in n places, these signals will be emitted n times. This gets us exponential behavior for deep widget hierarchies. However, I do not care enough to do anything about this and this should still behave way better than what we had before.) Oh and since I didn't mention it yet: This code creates a cairo surface, places some widgets on it, forces a redraw of one of these widgets, then forces a relayout for one of the widgets and finally saves the resulting cairo surface to "out.png". During this, it prints a message each time it calls a widget's callback to show that just the minimum amount of callbacks are generated. -- 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#comment4160 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 [email protected].
[awesome bugs] #1296 - Updated signal causes total relayout (Attachment added)
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)
--
Seems like I can't get this out of my head...
All of a widget's callbacks are now optional. Missing draw methods are just
skipped. A missing :layout() is the same as returning {} aka "no children".
When :fit() is missing, :layout() is used and the area covered by child widgets
is used for the return value.
(Oh and base.fit_widget() now also forces widgets to return a value between 0
and the given width/height)
--
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#comment4159
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 [email protected].
[awesome bugs] #1296 - Updated signal causes total relayout (Attachment added)
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) -- Another new version. This now introduces a layout cache similar to the fit cache. This removes the "wibox" argument for :fit() and :layout() since the result of these functions is cached and thus must not depend on the wibox. This also changes the API for :layout() so that it is no longer recursive. Instead, :layout() returns a table that describes all "child widgets" together with their positions and transformations. This table is cached. This change should also make it much easier to test things. You guys don't have to look through all the code in there, but it would be nice if you looked at the "fixed" and the "img" widgets in there (lines 269 to 359) and tell me if the API they use looks sensible. The other 250 lines in there just implement this API. Oh and another new change: The result from :fit() goes through math.ceil(). This should make it harder for introduce non-integer positions for widgets, although this is still easily possible... -- 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#comment4157 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 [email protected].
[awesome bugs] #1296 - Updated signal causes total relayout (Attachment added)
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) -- Attached is a quick prototype implementation of this. It only depends on gears.object and lgi. A widget has this callbacks: - :fit(wibox, width, height): Returns width and height that the widget wants to have, is called to assign sizes, must not have any side effect - :layout(wibox, width, height): Is called when the widget should place its children, must call base.place_widget(wibox, widget, matrix, width, height) for each child. Can use base.fit_widget(wibox, widget, width, height). Matrix transforms from this widget's coordinate space into the children's space. - :draw(wibox, cr, width, height) (and before_draw_children, after_draw_children): This is called when the widget should be drawn. This should just draw this widget on the given cairo context and doesn't have to interact with children. The two *_draw_children() do what their name suggests and can be e.g. used to set the cairo context's foreground color. Signals: - widget::redraw_needed: The various draw methods have to be called again. Only widgets which cover the same space are redrawn. - widget::layout_changed: Well, yeah, the layout needs to be changed. TODO: This still needs some magic to cache sub-layouts. Just like :fit() is cached in base.fit_widget, :layout() should be cached in base.place_widget() and this cache should only be invalidated from the widget::layout_changed signal. New compared to what we have right now: Layouts don't need to connect to any signals of their child widget since the wibox code does that for them. (The wibox code has to do this since it needs to figure out which area to redraw and I want to keep the widget hierachy private. But I bet someone will want to export it...) -- 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#comment4154 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 [email protected].
