Re: [Dillo-dev] bug tracking engine
On Sun, Feb 16, 2003 at 10:45:49PM +0100, Sebastian Geerken wrote:
I've been thinking about it (and hacking on dw_page.c) and have a partial implementation. It involved adding a pointer line->last_float_line which points to the last line that has a floater hanging down in the margin of the current line. Dw_page_draw_line() traces that pointer and draws that line too (and hence also its last_float_line and so on).
Dw_page_draw_line (which is called by Dw_page_draw, the implementation of DwWidget::draw) just does the actual drawing (putting the pixels on the screen), and since you cannot predict that it is called for all lines (normally it will be called for those lines seen in the viewport), it should not change the state of a DwPage.
It doesn't. Dw_page_draw_line() traces the pointer and causes possibly other lines to be drawn other than the one it is called for.
- Floats may exceed the allocation of the DwPage, so they may not be a child widget, instead, an interaction between two DwPage's is necessary.
When does a float exceed the allocation of the DwPage? Is there a new DwPage for new paragarphs?
- Since a float may be defined at a point, where there is already a float at the respective side, you do not only need one pointer, but rather a list or a tree, depending on how the second float is positioned (below or left/right, both is allowed by the CSS2 spec, but from what I've thought about it, I believe that the second variant is simpler to implement).
How about this: Floats are drawn in sequence just as other words on the line. Nothing special, except that now, line->ascent and line->descent doesnt count floats. Consequently, if the portion of the screen being refreshed doesn't yeild the DwPageLine where the float occurs, then that float wont get properly refreshed. The pointer points to the lowest (highest index) line containing a float that hangs down low enough that it may need to be refreshed also. (Note that if there's another float, then it will be either on the same line or refered back to by the pointer for the float line so that all the floats in the margin get refreshed.) Thanks.
On Tue, Feb 18, Joe Crayne wrote:
I've been thinking about it (and hacking on dw_page.c) and have a partial implementation. It involved adding a pointer line->last_float_line which points to the last line that has a floater hanging down in the margin of the current line. Dw_page_draw_line() traces that pointer and draws that line too (and hence also its last_float_line and so on).
Dw_page_draw_line (which is called by Dw_page_draw, the implementation of DwWidget::draw) just does the actual drawing (putting the pixels on the screen), and since you cannot predict that it is called for all lines (normally it will be called for those lines seen in the viewport), it should not change the state of a DwPage.
It doesn't. Dw_page_draw_line() traces the pointer and causes possibly other lines to be drawn other than the one it is called for.
If I have understood you correctly, you want Dw_page_draw_line to determine the positions of the floats. This will make calls to a_Dw_widget_size_allocate (for embedded child widgets) neccessary, which does change the state, at least of the widget tree. You really should put your code is Dw_page_size_request and Dw_page_size_allocate. Please read the documentations, both of Gtk+ (which is quite similar to Dw), and Dw. Especially, try to understand the implementation of "incremential resizing" (when something is unclear, I'll answer questions about it).
- Floats may exceed the allocation of the DwPage, so they may not be a child widget, instead, an interaction between two DwPage's is necessary.
When does a float exceed the allocation of the DwPage? Is there a new DwPage for new paragarphs?
Currently, nested DwPage's are used for: 1. any blocks with a margin different from zero (<blockqoute>, <ul> and some others): DwPage had originally the possibility to indent single blocks, but when I one redesigned DwPage (to fix a CPU lock), I decided to simplify it by removing this feature. 2. Any <li>, since this makes dealing width the hanging bullet/number much easier. (Paragraphs within list items were poorly rendered for a long time.)
- Since a float may be defined at a point, where there is already a float at the respective side, you do not only need one pointer, but rather a list or a tree, depending on how the second float is positioned (below or left/right, both is allowed by the CSS2 spec, but from what I've thought about it, I believe that the second variant is simpler to implement).
How about this: Floats are drawn in sequence just as other words on the line.
See above.
Nothing special, except that now, line->ascent and line->descent doesnt count floats. Consequently, if the portion of the screen being refreshed doesn't yeild the DwPageLine where the float occurs, then that float wont get properly refreshed.
That's exactly the point! Child widgets must *always* size_allocated, also when they are not visible. Sebastain
participants (2)
-
Joe Crayne -
Sebastian Geerken