diff options
| author | Sebastian Geerken <devnull@localhost> | 2015-06-03 22:40:07 +0200 |
|---|---|---|
| committer | Sebastian Geerken <devnull@localhost> | 2015-06-03 22:40:07 +0200 |
| commit | 0a565f9b2bfc084a3292ad0c3db85e76cc8dc060 (patch) | |
| tree | ae743c7a37bfde4293c142e4a6d32648526b7776 /devdoc/dw-miscellaneous.doc | |
| parent | da88ede8c401449729ae9c4b78f4c9914d81fa09 (diff) | |
Moved dev docs to devdoc.
Diffstat (limited to 'devdoc/dw-miscellaneous.doc')
| -rw-r--r-- | devdoc/dw-miscellaneous.doc | 187 |
1 files changed, 187 insertions, 0 deletions
diff --git a/devdoc/dw-miscellaneous.doc b/devdoc/dw-miscellaneous.doc new file mode 100644 index 00000000..d6b3cae3 --- /dev/null +++ b/devdoc/dw-miscellaneous.doc @@ -0,0 +1,187 @@ +/** \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). + + +Floats +====== + +Handling collisions +------------------- +The CSS specification allows two strategies to deal with colliding +floats: placing the second float beside or below the first one. Many +other browsers implement the first approach, while dillo implements +the second one, which may cause problems when the author assumes the +first. Example: the "tabs" at the top of every page at Wikipedia +("Article", "Talk", ...). + +Float containers in flow +------------------------ +Consider the following HTML snippet: + + <body> + <img src="....jpg" style="float:right"> + <p style="overflow:hidden">Text</p> + </body> + +Interestingly, dillo shows "Text" always *below* the image, even if +there is enough space left of it. An investigation shows that the +paragraph (<p>) is regarded as own floats container (because of +*overflow:hidden*), so the floats container above (<body>) +regards this block as widget which must be fit between the floats +(dw::Textblock::mustBorderBeRegarded > +dw::Textblock::getWidgetRegardingBorderForLine). However, since a +textblock in flow always covers (at least) the whole available width, +which is defined *without* considering floats, the space left of the +float will always be to narrow, so that the paragraph is moved below +the float, by inserting an empty line before. + +When searching for a solution, several difficulties show up: + +1. The available width, which is used for the width of the textblock, + is defined independent of floats. Aside from problems when changing + this definition, a dependance on floats would be difficult to + implement, since *sizeRequest* is independent of a position. (See + also \ref dw-out-of-flow.) +2. I must admit that I do not rembember the exact rationale and the + test case behind adding the exception in + dw::Textblock::getWidgetRegardingBorderForLine (see above), but + simply removing this exception will result in a possible + overlapping of floats from both containers, since no collisions are + tested for. +3. On the other hand, mixing the float containers (interaction of two + or more instances of dw::oof::OOFFloatsMgr), e. g. for + collision tests, would become too complex and possibly result in + performance problems. + +Instead, this approach is focussed: + +- Goal: the paragraph is narrowed so it fits, *as a whole*, between + the floats. +- The approach is to remove the exception in + dw::Textblock::getWidgetRegardingBorderForLine. A textblock, which + is a float container in flow (as this paragraph), is returned by + this method and so dw::Textblock::mustBorderBeRegarded returns + *true*. This will put this paragraph again at the correct position. +- To avoid overlappings, the linebreaking width of this paragraph + (which is also used for positioning of floats) is the available + width, minus the maximal float width on either side. (This is an + approach similar to the one dw::Ruler will use soon). Most likely, + some new methods will have to be added to calculate this. +- For paragraphs like this, dw::Textblock::borderChanged must rewrap + all lines; *y* is irrelevant in this case. +- Since the textblock will tend to become taller when getting + narrower, and so possibly cover more (wider) floats, and so become + narrower again etc., there may be multible solutions for calculating + the size. Generally, a smaller height (and so larger width) is + preferred. +- There remains a problem: what if a word is too large? Should a + textblock of this kind then reard the floats in detail, to insert + empty lines when needed? + +**Real-world cases:** *Overflow:hidden* is set for headings in +Wikipedia, and so this case occurs when there is a float (thumb image) +before a heading. See e. g. +<a href="http://de.wikipedia.org/wiki/Emmerich_am_Rhein#Ans.C3.A4ssige_Unternehmen">this page</a> +and scroll a bit up; the company logos should be right of this section. + +**Priority:** Since this is not a regression, compared to not +supporting floats at all, a fix is not urgent for a new release. + +Positioned elements +=================== + +General +------- +(See also *relative positions* below.) + +What about negative positions? + +dw::oof::OutOfFlowMgr::tellPosition1 and +dw::oof::OutOfFlowMgr::tellPosition2 could be combined again, and +called in the respective circumstance, depending on +dw::oof::OutOfFlowMgr::mayAffectBordersAtAll. + +Relative positions +------------------ +**General Overview:** At the original position, a space as large as +the positioned element is left. This is implemented by assigning a +size to the widget *reference*. For this there are two new methods: +dw::oof::OutOfFlowMgr::calcWidgetRefSize and +dw::oof::OOFAwareWidget::widgetRefSizeChanged. + +**Bug:** Since the size of a relatively positioned element should be +calculated as if it was in flow, the available width should be +delegated to the *generator*; however, since +dw::oof::OOFPosRelMgr::dealingWithSizeOfChild returns *false* in all +cases, it is delegated to the *container*. **Idea for fix:** +dw::oof::OOFPosRelMgr::dealingWithSizeOfChild should return *false* if +and only if the generator of the child is the container (to prevent an +endless recursion). In other cases, +dw::oof::OOFPosRelMgr::getAvailWidthOfChild and +dw::oof::OOFPosRelMgr::getAvailHeightOfChild should directly call the +respective methods of the *generator*, which must be made public then. + +**Performance:** In many cases, the first call of +dw::oof::OOFPosRelMgr::sizeAllocateEnd will queue again the resize +idle, since some elements are not considered in +dw::oof::OOFPosRelMgr::getSize. One case could be removed: if a +positioned element has *left* = *top* = 0, and its total size (the +requisition) is equal to the space left at the original position, the +size of the widget *reference* +(dw::oof::OOFAwareWidget::getRequisitionWithoutOOF, see +dw::oof::OOFPosRelMgr::calcWidgetRefSize). + +**Documentation:** Describe why the latter is not covered by +dw::oof::OOFPositionedMgr::doChildrenExceedContainer. (Is this really +the case?) + +**Open:** Stacking order? Furthermore: a relatively positioned element +does not always constitute a containing block (see CSS specification). + +Fixed positions +--------------- +Currently, fixedly positioned elements are positioned relative to the +canvas, not to the viewport. For a complete implementation, see \ref +dw-fixed-positions. + +*/ |