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 - Vlad Leberstein (owl) ---------- Thanks for your explanation and sorry for my late response! I've investigated a little bit further and now tend to think that Awesome should really borrow the approach to widget system from popular GUI toolkits. These are the ideas which I came across and have partially implemented(but it's too hackish to show anything right now): 1) Widget's "layout" and "draw" operations are separated i.e. relayout shouldn't be triggered by redraw and vice versa. This enables us to make "draw" method optional. E.g. align's "draw" doesn't really draw anything - it simply recalculates extents of it's children. So when there is no "draw" method in any of the widget's children, we can simpy traverse the tree until child's descendants with draw implemented are found. Moreover, it may be a good idea to separate layout and render hierarchies completely(like geometry managers in TCL/Tk or sizers in WxWidgets) but I can't suggest anything specific right now. 2) Have a "dirty" flag in each widget. I.e. when the widget requests redraw, we determine the path through the widgets hierarchy and set the flag in all the widgets(or at least the ones with "draw" method) on that path. Then drawable performs normal "redraw everything" call but now layouts can make assumptions about what should and what shouldn't be redrawn. As for the corner cases you've outlined, I'm a little bit confused about why one widget can belong to more then one parent? It doesn't bring any additional functionality or save lots of resources, but will complicate the design of widgets hierarchy AFAIU so why bother? Also it doesn't seem quite logical to me that widgets should be allowed to draw outside of their clipping region. I understand the convenience of having such possibility but again, it would significantly complicate partial update mechanics. I imagine that system, where widgets can have multiple unconnected regions is implementable, but AFAIU it would require something like dynamic BVH tree creation to make all unconnected(by widget/layout hierarchy I mean) regions, which occupy the same screen space, automatically redraw themselves when any of them would request redraw. Or the widget hierarchy itself could be reimplemented as a more general graph but I have no idea about how to keep track of z-index of such regions... Anyway, does it really worth it? Am I overlooking something? Also by "a new event loop callback" do you mean an alternative to drawable:refresh()? I performed some very simple tests(not very accurate though) with my current implementation and I believe that coping updated surafce to XCB isn't the real bottleneck, is it? I would greatly appreciate any comments/advices because I don't have much experience in implementing more or less serious GUI systems and will definitely make use of any info provided. Thanks in advance for your help! PS: Sorry for any mistakes - English is not my mother tongue ---------- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1296#comment4147 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.
