Initial import of Dillo

devdoc/dw-miscellaneous.doc

@@ -0,0 +1,97 @@
+/** \page dw-miscellaneous Miscellaneous Notes on Dw
+
+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).
+
+General
+=======
+
+Widget allocation outside of parent allocation
+----------------------------------------------
+A widget allocation outside of the allocation of the parent is
+allowed, but the part outside is not visible.
+
+Which widgets may be drawn?
+---------------------------
+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:
+
+1. Direct descendants, which are not children, may be drawn, if the
+   parent can distinguish them and so omit drawing them a second
+   time. See dw::core::StackingContextMgr and \ref dw-stacking-context.
+   Parents should not draw children in flow for which
+   dw::core::StackingContextMgr::handledByStackingContextMgr returns
+   true.
+2. Interrupted drawing: via dw::core::Widget::drawInterruption; see
+   \ref dw-interrupted-drawing.
+
+Similar rules apply to handling mouse events
+(dw::core::Widget::getWidgetAtPoint).
+
+Interrupted drawing
+-------------------
+→ \ref dw-interrupted-drawing.
+
+Similar rules apply to handling mouse events
+(dw::core::Widget::getWidgetAtPoint).
+
+Extra space
+-----------
+Should dw::core::Widget::calcExtraSpace be called from
+dw::core::Widget::getExtremes?
+
+
+Widgets out of flow
+===================
+
+dw::Textblock::getGeneratorWidth
+--------------------------------
+Re-evaluate dw::Textblock::getGeneratorWidth (especially the limitation on
+instances of dw::Textblock) for positioned elements. Is this method really only
+called for floats?
+
+
+Widget sizes
+============
+
+Relation between dw::core::Widget::markSizeChange and  dw::core::Widget::queueResize
+------------------------------------------------------------------------------------
+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.
+
+<div style="text-decoration: line-through; color: #606060">
+dw::oof::OOFFloatsMgr::markSizeChange (called from
+dw::Textblock::markSizeChange) calls dw::oof::OOFAwareWidget::updateReference,
+whose implementation dw::Textblock::updateReference calls
+dw::core::Widget::queueResize. This may result in a recursion,
+
+- for which it is not clear whether it ends in all cases (although endless cases
+  are not known yet), and
+- which nevertheless may take much time in cases where the number of calls
+  increases exponentially with the depth of the widget tree.
+
+The recent change in dw::Textblock::updateReference (`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.
+
+Here is the original test case (slow, when `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.html
+
+You may change the number (20), or examine smaller cases with
+<a href="http://home.gna.org/rtfl/">RTFL</a>:
+
+    (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
+</div>
+
+*/