From 38084cbc8a15c236bceb247492160106de2f8d3e Mon Sep 17 00:00:00 2001 From: Sebastian Geerken Date: Sun, 1 Nov 2015 12:58:49 +0100 Subject: Clean up documentation for Elements OOF (at least remove irrelevant parts). --- devdoc/dw-miscellaneous.doc | 142 -------------------- devdoc/dw-out-of-flow-2.doc | 69 ---------- devdoc/dw-out-of-flow-floats.doc | 156 ++++++++++++---------- devdoc/dw-out-of-flow-positioned.doc | 63 +++++++++ devdoc/dw-out-of-flow.doc | 242 +++++++---------------------------- 5 files changed, 196 insertions(+), 476 deletions(-) delete mode 100644 devdoc/dw-out-of-flow-2.doc create mode 100644 devdoc/dw-out-of-flow-positioned.doc diff --git a/devdoc/dw-miscellaneous.doc b/devdoc/dw-miscellaneous.doc index d6b3cae3..cb4303c2 100644 --- a/devdoc/dw-miscellaneous.doc +++ b/devdoc/dw-miscellaneous.doc @@ -42,146 +42,4 @@ 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: - - -

Text

- - -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. -this page -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. - */ diff --git a/devdoc/dw-out-of-flow-2.doc b/devdoc/dw-out-of-flow-2.doc deleted file mode 100644 index d9d70565..00000000 --- a/devdoc/dw-out-of-flow-2.doc +++ /dev/null @@ -1,69 +0,0 @@ -/** \page dw-out-of-flow-2 Handling Elements Out Of Flow (notes 2) - -This has to be integrated into \ref dw-out-of-flow. - -Constructing a page with floats -------------------------------- -When a page is constructed (dw::Textblock::addWord), the *generating* -block tells the positions of floats (or, generally, widgets out of -flow) via dw::OutOfFlowMgr::tellPosition. This method considers -already collisions with other floats (only previous floats; floats -following this float are not considered); after the call, -dw::OutOfFlowMgr::getBorder will return correct values. - -dw::OutOfFlowMgr::tellPosition also checks for overlaps of this float -with other textblocks, except this textblock (the *generator*, which -is just constructed, so nothing has to be done). The fact that the -position of the float is the top, and so the float has only an -allocation below this position, leads to the effect that only the -textblocks following the generator are affected. (**Check:** Can the -search be limited here?) When a page is constructed, no textblocks -should be following the generating block, so no textblocks are -affected. - -**Todo:** Clarify details of line breaking (\ref dw-line-breaking). - -Float changes its size ----------------------- -The float itself will call queueResize, which will result in a call of -markSizeChange for the *containing* block, which will then call -dw::OutOfFlowMgr::markSizeChange. Here, the vloat is only *marked* as -dirty; the size will be calculated later (in -dw::OutOfFlowMgr::ensureFloatSize). - -This will trigger the resize idle function, so sizeRequest and -sizeAllocate for all floats and textblocks. In this run, -dw::OutOfFlowMgr::hasRelationChanged will return *true*, and so result -in a call of dw::Textblock::borderChanged, and trigger a second run of -the resize idle function, dealing correctly with the new size. - -(This case is handles in a not perfectly optimal way, since two runs -of the resize idle function are neccessary; but size changes of floats -is not a very common case. - -When a page is constructed (see above), a changing size of a float -currently constructed typically only affects the most bottom -textblock; the other textblocks are not covered by this float.) - -**Error:** In this case, new collisions are not yet considered. - - -Changing the width of the page ------------------------------- - -When the page width is changed, this will result in a reconstruction -of the page; see *Constructing a page with floats*. Anyway, checking -for overlaps will play a more important role. This is handled in an -optimal way by dw::OutOfFlowMgr::hasRelationChanged. - -**Check:** Are "cascades" avoided, like this: - -1. All textblocks are constructed. A float in textblock 1 overlaps - with textblock 2, so dw::Textblock::borderChanged is called for - textblock 2. -2. In another resize idle run, textblock 2 is constructed again. A - float in textblock 2 overlaps with textblock 3, so that - dw::Textblock::borderChanged is called for textblock 3. -3. Etc. - -*/ \ No newline at end of file diff --git a/devdoc/dw-out-of-flow-floats.doc b/devdoc/dw-out-of-flow-floats.doc index 53c6b220..6d0777fc 100644 --- a/devdoc/dw-out-of-flow-floats.doc +++ b/devdoc/dw-out-of-flow-floats.doc @@ -1,73 +1,9 @@ /** \page dw-out-of-flow-floats Handling Elements Out Of Flow: Floats -(Note: Bases on work at , I plan -to split the documentation on elements out of flow into different -parts: general part, floats, positioned elements. In this document, -informations about floats are collected.) +TODO: Much missing. - -GB lists and CB lists -===================== - -Floats generated by a block which is not yet allocated are initially -put into a list related to the *generator*: - -- dw::OutOfFlowMgr::TBInfo::leftFloatsGB or -- dw::OutOfFlowMgr::TBInfo::rightFloatsGB. - -These lists are also called GB lists. - -Floats of allocated generators are put into lists related to the -*container* (called CB lists): - -- dw::OutOfFlowMgr::leftFloatsCB or -- dw::OutOfFlowMgr::rightFloatsCB. - -As soon as the container is allocated, all floats are moved from the -GB lists to the CB lists (dw::OutOfFlowMgr::sizeAllocateStart → -dw::OutOfFlowMgr::moveFromGBToCB). - -Here, it is important to preserve the *generation order* (for reasons, -see below: *Sorting floats*), i. e. the order in which floats have -been added (dw::OutOfFlowMgr::addWidgetOOF). This may become a bit -more complicated in a case like this: - - - - - -

float 1

float 2

float 3

- - -The floats are generated in this order: - -- \#fl-1 (generated by \#bl-1), -- \#fl-2 (generated by \#bl-2), -- \#fl-3 (generated by \#bl-1). - -Since the floats must be moved into the CB list in this order, it -becomes clear that the floats from one GB list cannot be moved at -once. For this reason, each float is assigned a "mark", which is -different from the last one as soon as the generator is *before* the -generator of the float added before. In the example above, there are -three generators: body, \#bl-1, and \#bl-2 (in this order), and floats -are assigned these marks: - -- \#fl-1: 0, -- \#fl-2: also 0, -- \#fl-3 is assigned 1, since its generator (\#bl-1) lies before the - last generator (\#bl-2). - -dw::OutOfFlowMgr::moveFromGBToCB will then iterate over all marks, so -that the generation order is preserved. +(Historical) Note: Floats make use of dw-size-request-pos, which reduces the +complexity of a previous design. Sorting floats @@ -118,4 +54,90 @@ block, for both floats and child blocks. dw::OutOfFlowMgr::Float::ComparePosition ... + +Miscellaneous notes +=================== + +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: + + +

Text

+ + +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. +this page +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. + */ diff --git a/devdoc/dw-out-of-flow-positioned.doc b/devdoc/dw-out-of-flow-positioned.doc new file mode 100644 index 00000000..9269c49d --- /dev/null +++ b/devdoc/dw-out-of-flow-positioned.doc @@ -0,0 +1,63 @@ +/** \page dw-out-of-flow-positioned Handling Elements Out Of Flow: Positioned Elements + +TODO + + +Miscellaneous notes +=================== + +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. + +*/ diff --git a/devdoc/dw-out-of-flow.doc b/devdoc/dw-out-of-flow.doc index eda6994a..3dc7163b 100644 --- a/devdoc/dw-out-of-flow.doc +++ b/devdoc/dw-out-of-flow.doc @@ -1,44 +1,9 @@ /** \page dw-out-of-flow Handling Elements Out Of Flow -

Info: -Not up to date; incorporate these two changes: (i) there are different -containing blocks for floats and absolutely (furthermore also fixedly) -positioned elements; (ii) dw::oof::OutOfFlowMgr is now only the base -class; floats and absolutely positioned elements are seperated: -\dot -digraph G { - node [shape=record, fontname=Helvetica, fontsize=10]; - edge [arrowhead="none", arrowtail="empty", dir="both"]; - fontname=Helvetica; fontsize=8; - - OutOfFlowMgr [URL="\ref dw::oof::OutOfFlowMgr"; color="#a0a0a0"]; - OOFFloatsMgr [URL="\ref dw::oof::OOFFloatsMgr"]; - OOFPositionedMgr [URL="\ref dw::oof::OOFPositionedMgr"; color="#a0a0a0"]; - OOFPosAbsLikeMgr [URL="\ref dw::oof::OOFPosAbsLikeMgr"; color="#a0a0a0"]; - OOFPosAbsMgr [URL="\ref dw::oof::OOFPosAbsMgr"]; - OOFPosFixedMgr [URL="\ref dw::oof::OOFPosFixedMgr"]; - OOFPosRelMgr [URL="\ref dw::oof::OOFPosRelMgr"]; - - OutOfFlowMgr -> OOFFloatsMgr; - OutOfFlowMgr -> OOFPositionedMgr; - OOFPositionedMgr -> OOFPosAbsLikeMgr; - OOFPosAbsLikeMgr -> OOFPosAbsMgr; - OOFPosAbsLikeMgr -> OOFPosFixedMgr; - OOFPositionedMgr -> OOFPosRelMgr; -} -\enddot -

- -

Info: -A simplification is ongoing, see \ref dw-size-request-pos. -

- Introduction ============ -This texts deals with both floats and absolute positions, which have +This texts deals with both floats and positioned elements, which have in common that there is a distinction between generating block and containing block (we are here using the same notation as in the CSS 2 specification). Consider this snippet (regarding floats): @@ -76,177 +41,58 @@ their borders, and so their size. In this example, the following list item (green) must consider the position of the float. This is discussed in detail in the next section.) -Both in this text and the code, generating and containing block are -abbreviated with **GB** and **CB**, respectively. - Implementation overview ======================= -Widget level ------------- -The terms *generating block* and *containing block* have been raised -to a higher level, the one of dw::core::Widget, and are here called -*generating widget* and *containing widget*. To represent the -distinction, the type of dw::core::Content has been split into three -parts: - -- If a widget is out of flow, the generating widget keeps a reference - with the type dw::core::Content::WIDGET_OOF_REF, while the - containing block refers to it as dw::core::Content::WIDGET_OOF_CONT. -- For widgets within flow, dw::core::Content::WIDGET_IN_FLOW is used. - -Notice that in the first case, there are two pieces of content -referring to the same widget. - -An application of this distinction is iterators. [TODO: more. And -still missing: DeepIterator may need the generating parent widget in -some cases.] - - -Textblock level ---------------- -Both dw::Textblock::notifySetAsTopLevel and -dw::Textblock::notifySetParent set the member -dw::Textblock::containingBlock appropriately, (according to rules -which should be defined in this document). - -Handling widgets out of flow is partly the task of the new class -dw::oof::OutOfFlowMgr, which is stored by dw::Textblock::outOfFlowMgr, -but only for containing blocks. Generating blocks should refer to -*containingBlock->outOfFlowMgr*. (Perhaps dw::oof::OutOfFlowMgr may -become independent of dw::Textblock.) - -dw::Textblock::addWidget is extended, so that floats and absolutely -positioned elements can be added. Notice that not *this* widget, but -the containing block becomes the parent of the newly added child, if -it is out of flow. dw::Textblock::addWidget decides this by calling -dw::oof::OutOfFlowMgr::isOutOfFlow. (See new content types above.) - -dw::core::Widget::parentRef has become a new representation. Before, -it represented the line numer. Now (least signifant bit left): - - +---+ - - - +---+---+- - - - - -+---+---+---+---+ - | line number | 0 | - +---+ - - - +---+---+- - - - - -+---+---+---+---+ - - +---+ - - - +---+---+- - - - - -+---+---+---+---+ - | left float index | 0 | 0 | 1 | - +---+ - - - +---+---+- - - - - -+---+---+---+---+ - - +---+ - - - +---+---+- - - - - -+---+---+---+---+ - | right float index | 1 | 0 | 1 | - +---+ - - - +---+---+- - - - - -+---+---+---+---+ - - +---+ - - - +---+---+- - - - - -+---+---+---+---+ - | absolutely positioned index | 1 | 1 | - +---+ - - - +---+---+- - - - - -+---+---+---+---+ - -Details are hidden by static inline methods of dw::oof::OutOfFlowMgr. - - -The sizeRequest/sizeAllocate problem -==================================== - -*See also:* \ref dw-widget-sizes, especially the section *Rules for -Methods Related to Resizing*. - -The size/position model of ::dw consists mainly of the following two -steps: - -1. First, the size of the toplevel widget is calculated. Size - calculation typically depends on the sizes of the widgets, which - are calculated recursively, but not more. -2. After this, the toplevel widget is allocated at position (0, 0), - with the previosly calculated size. Each widget must allocate its - children; here, the condition for the toplevel widget (allocated - size equals requested size) is not necessary; instead, each widget - may be allocated at every size. - -Especially for floats, this model becomes a bit difficult, for reasons -described below. For the solutions, much is centralized at the level -of the containing block, which delegates most to an instance of -dw::oof::OutOfFlowMgr (details below). - -**The size of a widget depends on the size not only of the children.** -In the example above, the last list item (green, following the -generating list item) must know the size of the the float (which is -not a child or, generally, descendant) to determine the borders, which -is done in dw::Textblock::sizeRequestImpl. - -For this, the size model has been extended (see \ref dw-widget-sizes, -section *Rules for Methods Related to Resizing*): *sizeRequest* can be -called within *sizeRequestImpl* for other widgets that children (with -some caution). Namely, dw::Textblock::sizeRequestImpl calls -dw::core::Widget::sizeRequest for the float, via -dw::oof::OutOfFlowMgr::getBorder and -dw::oof::OutOfFlowMgr::ensureFloatSize. - -**The size of a widget depends on the allocation of another widget.** -In the example above, both list items (blue and green) must know the -position of the float widget, within dw::Textblock::sizeRequestImpl, -to calculate the borders. The position, however, is stored in the -allocation, which is typically calculated later. - -Here, two cases must be distinguished. The position of a float is -always **relative to its generating block**, so for calculating the -borders for the generating block, the allocation needs not to be -know. For other textblocks, it needs to be known, so the calculation -of the borders will ignore floats generated by other textblocks, until -all widgets are allocated. The latter will call (when neccessary) -dw::core::Widget::queueResize, so that all border calculations are -repeated. See below (*hasRelationChanged*) for details. - -Generally, this pattern (distinguishing between GB and CB) can be -found everywhere in dw::oof::OutOfFlowMgr. - -For details see: - -- dw::oof::OutOfFlowMgr::getLeftBorder, - dw::oof::OutOfFlowMgr::getRightBorder, - dw::oof::OutOfFlowMgr::getBorder (called by the first two), and - especially, dw::oof::OutOfFlowMgr::getFloatsListForTextblock (called - by the latter), where these three cases are distinguished; -- dw::oof::OutOfFlowMgr::sizeAllocateStart, - dw::oof::OutOfFlowMgr::sizeAllocateEnd which are called by the - containing block. - -(This could be solved in a more simple, elegant way, when -*sizeRequest* would depend on the position. This is, however, only a -vague idea, perhaps not even feasible, and for which there are no -concrete plans, certainly not in \ref dw-grows.) - - -Implementation details -====================== - -- CB and GB lists (general pattern) (see previous section) -- binary search; different search criteria, how they accord -- lastLeftTBIndex, lastRightTBIndex etc. -- limitiation of search; extIndex etc. - - -How *hasRelationChanged* works -============================== - -... - - -Integration of line breaking and floats -======================================= - -(Positioning of floats, loop, recent works.) +- dw::oof::OOFAwareWidget is the base for both generators and containers. + dw::Textblock and dw::Table are based on this, but dw::Table is only relevant + for positioned elements, so much simpler than dw::Textblock. +- Different containers for floats, absolutely positioned elements etc. +- If a widget is out of flow, the generating widget keeps a reference with the + type dw::core::Content::WIDGET_OOF_REF, while the containing block refers to + it as dw::core::Content::WIDGET_OOF_CONT. For widgets within flow, + dw::core::Content::WIDGET_IN_FLOW is used. Notice that in the first case, + there are two pieces of content referring to the same widget. An application + of this distinction is iterators. (For selection and searching, the generating + hierarchy is used, whih is different from the widget hierarchy.) + +Handling widgets out of flow is partly the task of class implementing +dw::oof::OutOfFlowMgr, which is stored by dw::oof::OOFAwareWidget::outOfFlowMgr, +but only for containing blocks. Generating blocks should refer +to *container->outOfFlowMgr[...]*. + +Overview of the dw::oof::OutOfFlowMgr hierarchy; +\dot +digraph G { + node [shape=record, fontname=Helvetica, fontsize=10]; + edge [arrowhead="none", arrowtail="empty", dir="both"]; + fontname=Helvetica; fontsize=8; -Absolute and fixed positiones -============================= + OutOfFlowMgr [URL="\ref dw::oof::OutOfFlowMgr"; color="#a0a0a0"]; + OOFFloatsMgr [URL="\ref dw::oof::OOFFloatsMgr"]; + OOFPositionedMgr [URL="\ref dw::oof::OOFPositionedMgr"; color="#a0a0a0"]; + OOFPosAbsLikeMgr [URL="\ref dw::oof::OOFPosAbsLikeMgr"; color="#a0a0a0"]; + OOFPosAbsMgr [URL="\ref dw::oof::OOFPosAbsMgr"]; + OOFPosFixedMgr [URL="\ref dw::oof::OOFPosFixedMgr"]; + OOFPosRelMgr [URL="\ref dw::oof::OOFPosRelMgr"]; -To be documented. + OutOfFlowMgr -> OOFFloatsMgr; + OutOfFlowMgr -> OOFPositionedMgr; + OOFPositionedMgr -> OOFPosAbsLikeMgr; + OOFPosAbsLikeMgr -> OOFPosAbsMgr; + OOFPosAbsLikeMgr -> OOFPosFixedMgr; + OOFPositionedMgr -> OOFPosRelMgr; +} +\enddot + -See also -======== +Further details +=============== -→ \ref dw-miscellaneous. +- \ref dw-out-of-flow-floats +- \ref dw-out-of-flow-positioned */ -- cgit v1.2.3