Dillo v3.1.1-91-g6d5b3ee3
|
This is a barely sorted list of issues which I consider noteworthy, but have yet to be moved to other parts of the documentation (which is partly to be created).
A widget allocation outside of the allocation of the parent is allowed, but the part outside is not visible.
All drawing starts with the toplevel widget (cf. dw::core::Widget::queueDrawArea, dw::core::Layout::queueDraw, and dw::core::Layout::expose), and a widget has to draw its children, in a way consistent with their stacking order.
There are two exceptions:
Similar rules apply to handling mouse events (dw::core::Widget::getWidgetAtPoint).
Similar rules apply to handling mouse events (dw::core::Widget::getWidgetAtPoint).
Should dw::core::Widget::calcExtraSpace be called from dw::core::Widget::getExtremes?
Re-evaluate dw::Textblock::getGeneratorWidth (especially the limitation on instances of dw::Textblock) for positioned elements. Is this method really only called for floats?
The following comment should be re-evaluated. Implementing incremental resizing for dw::oof::OOFFloatsMgr seems to fix the performance problems, but this should be examined further.
if (lines->size () > 0)
) seems to fix the performance problem, but the issue should be examined further, albeit with lower priority. Especially, it has to be determined, under which conditions it is allowed to (directly or indirectly) call dw::core::Widget::queueResize within an implementation of dw::core::Widget::markSizeChange.if (lines->size () > 0)
is removed again): (for i in $(seq 1 20); do echo '<div style="float:left"><div></div>'; done) > tmp.html; src/dillo tmp.htmlYou may change the numner (20), or examine smaller cases with RTFL:
(for i in $(seq 1 3); do echo '<div style="float:left"><div></div>'; done) > tmp.html; src/dillo tmp.html | rtfl-objview -OM -A "*" -a resize -a resize.oofm